DVA-C02 Security Practice Question

A company has an IAM policy that allows s3:GetObject for all users in the account. However, a specific user is receiving access denied errors. Which THREE possible causes should the developer investigate?

⚠ Common exam trap

DVA-C02 often tests the misconception that an Allow in an IAM policy is sufficient for access, when in fact any explicit Deny at the SCP, identity, or bucket-policy layer overrides it.

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

✓

An SCP at the organization level denies s3:GetObject.

Option A is correct because AWS Organizations service control policies (SCPs) act as permissions guardrails that limit the maximum permissions for accounts in the organization; an SCP that denies s3:GetObject overrides the account-level IAM allow, producing Access Denied. Option C is correct because an explicit Deny in any attached IAM policy (identity-based) always wins over an Allow in the same or another policy, so a deny statement for s3:GetObject on the user's role blocks the action. Option E is correct because S3 bucket policies are resource-based policies evaluated alongside IAM policies, and an explicit Deny in the bucket policy for that user (or principal) overrides the account's Allow, resulting in Access Denied. Option B is not correct because using an incorrect regional endpoint typically causes connection or redirect errors (e.g., 301/PermanentRedirect), not an authorization Access Denied for a valid request. Option D is not correct because cross-account access is possible when the bucket policy grants permission to the external principal; being in a different account alone does not cause Access Denied.

Answer analysis

Option-by-option breakdown

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

✓
An SCP at the organization level denies s3:GetObject.
Why this is correct
Service control policies in AWS Organizations override account-level IAM grants, so an SCP denying s3:GetObject blocks access even though the identity policy allows it. This satisfies the stem's constraint: a user with an explicit allow still receives Access Denied, because SCPs cap effective permissions for all principals in the member account.
✗
The user is using an incorrect region endpoint.
Why it's wrong here
Region endpoints do not affect authorisation: IAM evaluates identity policies independently of which regional endpoint serves the request, and S3 returns access denied regardless. It is tempting because endpoint misconfiguration causes connectivity failures, and would be correct where requests time out or resolve incorrectly rather than being denied.
✓
The user's IAM role has an attached policy that denies s3:GetObject.
Why this is correct
An explicit Deny in an identity-based policy overrides the account-level Allow, because IAM evaluates all applicable policies and any Deny wins. This directly satisfies the stem's scenario: the user belongs to the account where s3:GetObject is allowed, yet the attached role policy's Deny blocks the request, producing Access Denied.
✗
The S3 bucket is in a different AWS account.
Why it's wrong here
Cross-account bucket ownership does not itself deny access; the identity policy in the user's account still grants s3:GetObject, and only a bucket policy or ownership mismatch blocks it. It is tempting because cross-account access commonly needs explicit bucket policies, and would be correct where no such policy grants the principal access.
✓
A bucket policy explicitly denies the user.
Why this is correct
An explicit Deny in a bucket policy overrides the account-level Allow, because IAM evaluates identity-based and resource-based policies together and any Deny wins. This directly satisfies the stem's scenario: the user's s3:GetObject permission is negated by the bucket policy's explicit denial, producing Access Denied.

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

DVA-C02 Security Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question