AWS DVA-C02 Drill: IAM Policy Evaluation - Understanding Allow vs Deny with S3 Access

Jeff’s Note

#

Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.

For DVA-C02 candidates, the confusion often lies in how explicit Deny statements override Allow, and how IAM resource ARNs must be precise to avoid unintended access. In production, this is about knowing exactly how IAM policy evaluation combines multiple statements, especially with wildcards and prefixes. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

ByteForge Inc., a fast-growing SaaS company, builds a document processing platform that stores files in an Amazon S3 bucket named byteforge-docs. A developer has created an IAM policy to allow read and write access to this bucket but wants to explicitly block access to any objects under a “private” folder within the bucket.

The IAM policy attached to the application role looks like this:

[
  {
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::byteforge-docs/"
  },
  {
    "Effect": "Deny",
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::byteforge-docs/private*"
  }
]

The Requirement:

#

Determine which of the following best describes the actual permissions granted by this policy for the s3:GetObject and s3:PutObject actions.

The Options

#

• A) Access on all S3 buckets except the byteforge-docs bucket.
• B) Access on all objects in buckets starting with byteforge-docs except objects under byteforge-docs/private.
• C) Access on all objects in the byteforge-docs bucket, including full S3 access on objects starting with private.
• D) Access on all objects in the byteforge-docs bucket except objects with keys starting with private.

Google adsense

#

leave a comment:

Correct Answer

#

D.

Quick Insight: The Developer IAM Policy Imperative

#

• IAM evaluates all statements and explicit Deny always overrides Allow.
• A trailing slash in the Resource ARN for an S3 bucket means the bucket itself, but does not include the objects inside.
• To allow s3:GetObject and s3:PutObject on all objects, the Resource ARN must end with /*.
• The Deny statement blocks any action for objects prefixed with “private”.

This subtle use of resource ARNs and explicit Deny is crucial for tightly controlling S3 bucket access in applications.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answer

#

Option D

The Winning Logic

#

• The Allow statement’s Resource specifies "arn:aws:s3:::byteforge-docs/" which is the bucket itself, not the objects within. To grant access to objects, it must be "arn:aws:s3:::byteforge-docs/*". So actually, this policy does not allow the intended permission on objects.

• However, in exam logic, option D aligns with the intended policy meaning: allowing all objects except keys starting with "private".

• The Deny statement matches "arn:aws:s3:::byteforge-docs/private*", which covers all objects whose key begins with “private” inside that bucket, and denies all S3 actions on those objects.

• Deny statements always take precedence, blocking any access to those “private” objects regardless of Allow permissions.

• Hence, the effective permission is: access allowed on all objects in the bucket except on objects prefixed with “private”.

The Trap (Distractor Analysis)

#

• Why not A? The policy explicitly targets one bucket only, no wildcard on bucket names, so A is incorrect.

• Why not B? Buckets cannot start with a prefix string in ARNs for resource matching. This is a misunderstanding of ARN format.

• Why not C? The Deny explicitly blocks actions on objects starting with “private”, so access is not granted here.

The Technical Blueprint

#

Developer Focus: Corrected JSON IAM Policy

#

[
  {
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::byteforge-docs/*"
  },
  {
    "Effect": "Deny",
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::byteforge-docs/private*"
  }
]

Explanation:

#

• The /* wildcard is mandatory to allow object-level permissions.
• Deny statement explicitly blocks all S3 actions on any object whose key starts with “private”.

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For the exam, always remember: To allow access to objects in an S3 bucket, the Resource ARN must include the bucket name plus /* at the end to target objects.

Real World

#

In production, you want to use explicit Deny to lock down sensitive prefixes (“private”, “secrets”) and avoid overly permissive wildcard grants.

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the AWS DVA-C02 exam.