DOP-C02 Security and Compliance Practice Question

A security audit reveals that an S3 bucket contains objects that are publicly accessible. The DevOps engineer must prevent any future public access to the bucket and all objects within it. Which THREE actions should the engineer take? (Choose THREE.)

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

✓

Enable Block Public Access settings on the bucket.

Enabling block public access settings on the bucket prevents any future public access, including through ACLs or bucket policies. Option C is correct because removing any bucket policy that grants public read access eliminates one potential vector for public access. Option D is correct because applying an SCP that denies s3:PutBucketPolicy actions that would make objects public ensures that no account in the organization can create a policy that grants public access. Option B is incorrect because disabling object ACLs only removes one method of granting public access; bucket policies can still allow public access. Option E is incorrect because enabling server access logging helps with auditing but does not prevent public access.

Answer analysis

Option-by-option breakdown

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

✓
Enable Block Public Access settings on the bucket.
Why this is correct
Enabling Block Public Access (BPA) on the bucket is the correct immediate remediation because it applies four distinct settings—BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets—that override all existing and future public access grants, including those from object ACLs, bucket policies, and access point policies. This is the most direct and comprehensive way to seal the bucket at the resource level until a full audit can be completed, and it prevents accidental re-publication through any subsequent misconfiguration.
✗
Disable object ACLs on the bucket.
Why it's wrong here
Disabling object ACLs is insufficient because public access can be granted through many other channels, including bucket policies, access point policies, and the bucket's own ACL. While disabling ACLs entirely (or setting the ObjectOwnership to BucketOwnerEnforced) removes the ability to grant public read via individual object ACLs, it does nothing to neutralize an existing bucket policy that explicitly allows the AllUsers principal. Public exposure is only fully remediated when all permission vectors are addressed simultaneously, and this action alone leaves the bucket still publicly readable.
✓
Remove any bucket policy that grants public read access.
Why this is correct
Removing any bucket policy that grants public read access directly revokes the principal-level permission that is most commonly responsible for widespread exposure. A bucket policy with an Effect:Allow and a Principal of * or the canonical public group `http://acs.amazonaws.com/groups/global/AllUsers` is an explicit, top-level grant that immediately makes all objects readable regardless of object ACLs. This is a necessary corrective action, but it only addresses the policy vector: you must also sweep for object ACLs, and then apply Block Public Access to prevent recurrence.
✓
Apply an SCP that denies s3:PutBucketPolicy that would make objects public.
Why this is correct
Applying an SCP that denies s3:PutBucketPolicy (or s3:PutBucketPublicAccessBlock with a condition that permits only restricted configurations) is a robust preventive control at the organizational level, but it is not an immediate remediation for a bucket that is already public. SCPs only govern future API calls from accounts under the OU, so the existing permissive bucket policy or object ACLs remain in effect until explicitly removed. This is a strategic guardrail for governance, whereas the immediate fix requires action directly against the bucket's current policy and permissions.
✗
Enable S3 server access logging.
Why it's wrong here
Enabling S3 server access logging only records requests for audit and forensic purposes, providing a record of who accessed which object—it does not alter authorization in any way. Public read access granted via a bucket policy or object ACL continues to function unchanged while logs are captured, so this is purely detective, not corrective. Logging is valuable for post-incident analysis and compliance, but choosing it as the primary fix would leave the vulnerability completely active.

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 Security and Compliance Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question