DOP-C02 Configuration Management and IaC Practice Question
A company has a multi-account AWS environment using AWS Organizations. The DevOps team wants to enforce a policy that prevents creating S3 buckets with public read access. They plan to use AWS CloudFormation StackSets to deploy a stack across all accounts. What is the BEST way to enforce this policy?
⚠ Common exam trap
Many candidates confuse SCPs with IAM policies or resource-based policies, assuming that an SCP can only restrict IAM users and not API actions like s3:PutBucketPublicAccessBlock, or they mistakenly think that denying s3:PutBucketAcl is sufficient to prevent public read access when in reality bucket policies are a more common vector for granting public access.
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
✓
Create a service control policy (SCP) in the root organizational unit that denies the s3:PutBucketPublicAccessBlock action.
A service control policy (SCP) applied at the root organizational unit in AWS Organizations can centrally deny the s3:PutBucketPublicAccessBlock action across all accounts, effectively preventing any user or role from disabling the bucket-level public access block settings. This approach works even if an IAM principal has full administrative permissions, as SCPs act as a guardrail that cannot be overridden by account-level policies. It enforces the policy at the organization level without requiring per-account configuration or modifying individual IAM users.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use AWS CloudFormation Guard to validate templates before deployment and reject those with public access.
Why it's wrong here
CloudFormation Guard is a policy-as-code tool that only validates templates during CI/CD, so it can catch a public AccessControlList in a submitted template but cannot stop a user who has the s3:PutPublicAccessBlock permission from calling that API directly via console, CLI, or SDK. It also only inspects resources defined in CloudFormation, leaving existing buckets and ad-hoc operations entirely outside its enforcement.
- ✗
Create an IAM policy that denies s3:PutBucketAcl and attach it to all IAM users.
Why it's wrong here
Attaching an IAM policy to all IAM users does not govern the roles assumed by EC2 instances, Lambda functions, or other AWS services, which can still perform S3 actions, and it only targets the PutBucketAcl action. A malicious principal could simply call PutBucketPublicAccessBlock or PutBucketPolicy to enable public access, making the denial incomplete. Additionally, managing the same policy across every user is brittle and doesn't scale to new users unless enforced via SCP or permission boundaries.
- ✓
Create a service control policy (SCP) in the root organizational unit that denies the s3:PutBucketPublicAccessBlock action.
Why this is correct
An SCP attached to the root OU acts as an organization-wide permission guardrail, denying s3:PutPublicAccessBlock for every principal in all member accounts, regardless of IAM policies or account-level configurations. Since this action is a prerequisite for making a bucket publicly accessible through the console or API, explicitly denying it prevents bucket owners from disabling the public-access block that keeps objects private. This preventive control is the only option here that applies consistently across the entire AWS organization.
- ✗
Create an S3 bucket policy in each account that denies public read access.
Why it's wrong here
A bucket policy is resource-based and only governs the specific bucket to which it is attached, so adding deny-public-read policies to existing buckets in each account does not prevent a user from creating a new, unprotected bucket or from calling s3:PutBucketPublicAccessBlock. The action that needs to be controlled is the API call that configures public access, not the downstream read permission, and bucket policies are an after-the-fact mitigation that can be bypassed or left off a newly created resource. Without an account-wide or organization-wide control, this approach provides no assurance for new buckets.
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
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.