DOP-C02 Configuration Management and IaC Practice Question

An organization manages multiple AWS accounts using AWS Organizations. They want to enforce that all Amazon S3 buckets across accounts have versioning enabled. Which approach is the most scalable and least error-prone?

⚠ Common exam trap

Test-takers frequently choose AWS Config (Option A) because it is a common detective control, but they overlook that SCPs provide preventive enforcement at the organization level, which is more scalable and less error-prone for enforcing mandatory configurations across all accounts.

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 an SCP that denies s3:PutBucketVersioning if versioning is not enabled.

A Service Control Policy (SCP) in AWS Organizations can deny the `s3:PutBucketVersioning` action unless versioning is already enabled, effectively preventing the creation or modification of buckets without versioning. This approach is scalable as it applies to all accounts in the organization automatically and is least error-prone because it enforces the policy at the API level, blocking non-compliant actions before they occur.

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 Config rules to detect buckets without versioning and send alerts.
Why it's wrong here
AWS Config rules are reactive, evaluating resources after they exist and triggering alerts when a bucket lacks versioning. While you can pair a rule with an AWS Systems Manager Automation remediation to re-enable versioning, there is still a window during which the non-compliant bucket is accessible, and remediation can be throttled or fail. This option therefore detects and reports the issue but does not provide a preventive control that stops the unversioned bucket from being created or used.
✓
Create an SCP that denies s3:PutBucketVersioning if versioning is not enabled.
Why this is correct
An SCP attached at the root or OU can deny s3:PutBucketVersioning unless the request's VersioningState header is exactly 'Enabled', using a condition such as s3:x-amz-versioning. Because SCPs are evaluated before any IAM policies, a user in a member account cannot bypass this restriction even if their IAM policy allows the action, and the API call fails before any state change occurs. This preventive control enforces the organization-wide requirement that every bucket remain versioned, making it the correct answer.
✗
Deploy a CloudFormation StackSet to all accounts with a template that enables versioning.
Why it's wrong here
A CloudFormation StackSet can deploy a bucket versioning template to every account, but it only enforces configuration at deployment time and does not govern resources created outside CloudFormation. If an engineer manually creates a bucket without versioning or later changes the versioning state through the console, the StackSet does not automatically detect or revert that drift unless you continuously run drift detection and trigger a stack update, which is not a real-time preventive control. This approach is also operationally heavy and often lacks a central policy to stop ad-hoc bucket creation.
✗
Manually enable versioning on each bucket after creation.
Why it's wrong here
Manually enabling versioning after each bucket is created is an error-prone, post-hoc process that leaves a window of illegitimacy between bucket creation and the fix. It scales poorly across multiple accounts because it depends on engineers remembering a step and having the necessary permissions, and there is no automated verification to guarantee compliance. Without a central policy or audit trail, this approach cannot be considered a reliable method for enforcing an organization-wide data protection requirement.

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

DOP-C02 Configuration Management and IaC Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question