DEA-C01 Data Security and Governance Practice Question

A media company stores video files in an Amazon S3 bucket. The bucket policy allows access only from a specific VPC. The company has enabled S3 Server Access Logs to monitor access. Recently, the security team found that some requests were coming from an IP address outside the allowed VPC. They suspect that the bucket policy may have an incorrect condition. What should they check first?

⚠ Common exam trap

DEA-C01 often tests the confusion between diagnosing and fixing. Candidates might choose to review logs (Option B) as a first step, but the question asks what to check first to address the suspected policy condition error, making the policy condition the priority.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Verify that the bucket policy uses the 'aws:SourceVpc' condition key with the correct VPC ID.

The first thing to check is the bucket policy condition key. The 'aws:SourceVpc' condition key is used to restrict access to a specific VPC, but if it is misconfigured (e.g., wrong VPC ID or incorrect condition operator), requests from outside the VPC might be allowed. Verifying this key ensures the policy is correctly enforcing the VPC restriction.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Verify that the bucket policy uses the 'aws:SourceVpc' condition key with the correct VPC ID.
Why this is correct
The aws:SourceVpc condition key only matches when the request arrives through a VPC endpoint. A typo or wrong VPC ID in that condition lets external IP addresses bypass the intended restriction, so verify it first.
✗
Review the S3 Server Access Logs to identify the source IP addresses.
Why it's wrong here
Reading the logs only reports the offending source addresses; it cannot reveal which bucket policy condition permitted them, so the misconfigured condition remains unfixed. It is tempting because Server Access Logs are the standard tool for auditing S3 request origins, and would be correct when you need to establish who accessed a bucket rather than why the policy allowed it.
✗
Ensure that the IAM role used by the application has the correct permissions.
Why it's wrong here
IAM role permissions govern which actions a principal may perform, not which source network the request originates from, so they cannot explain an external IP. Checking IAM is tempting because access denials often stem from policy permissions, but here the source-IP condition is the suspect.
✗
Check if the bucket policy allows public access.
Why it's wrong here
Public access would permit anonymous requests, yet the observed requests still authenticate; the anomaly is a source-IP condition mismatch, not public exposure. Checking public access is tempting as a common S3 misconfiguration, but it does not address the VPC-scoped condition.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

DEA-C01 Data Security and Governance Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question