SCS-C02 Infrastructure Security Practice Question

Exhibit

Which TWO methods can be used to protect an S3 bucket from unauthorized access?

A security engineer needs to protect an S3 bucket that contains sensitive data. Which two methods should the engineer use?

⚠ Common exam trap

Candidates often confuse resource-based policies (bucket policies) with identity-based policies (IAM policies) and may think only one is sufficient, but the question asks for two methods, and both C and D are correct because they work together to enforce least-privilege 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

✓

Apply an S3 bucket policy that restricts access to specific IAM users or roles.

Option C is correct because an S3 bucket policy is a resource-based policy attached directly to the bucket that can explicitly allow or deny access based on principals (specific IAM users, roles, or accounts), conditions such as source VPC endpoint or IP range, and actions, making it the primary tool for restricting who can reach sensitive objects. Option D is correct because IAM policies are identity-based policies attached to users, groups, or roles that define which S3 actions (for example s3:GetObject, s3:PutObject) those identities may perform on the bucket and its objects; combined with the bucket policy, they enforce least-privilege access. Option A is not correct because CloudFront is a content-delivery service that can front an S3 bucket for performance or OAC-based access, but it does not by itself protect the bucket's data or restrict direct S3 access. Option B is not correct because VPC Flow Logs capture IP traffic metadata for network interfaces in a VPC and have no relationship to S3 bucket access control. Option E is not correct because S3 object ACLs are legacy access-control lists that grant only coarse read/write permissions to individual objects and are not the recommended mechanism for restricting sensitive bucket data to specific IAM principals.

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 Amazon CloudFront to serve the content.
Why it's wrong here
Amazon CloudFront is a content delivery network (CDN) that accelerates distribution of static content, but it does not control authorization to the underlying S3 bucket. While CloudFront can be integrated with S3 via Origin Access Control to hide direct bucket access, the service itself does not restrict which IAM users or roles can call GetObject or ListBucket on the origin. Using CloudFront alone would not prevent unauthorized access to the bucket if direct access remains open, so it is not the right mechanism for enforcing bucket-level access control.
✗
Enable VPC Flow Logs on the bucket.
Why it's wrong here
VPC Flow Logs capture metadata about IP traffic sent to and from elastic network interfaces in a VPC; they do not log or control S3 data-plane operations like GetObject, PutObject, or ListBucket. S3 access can be audited through AWS CloudTrail or S3 server access logs, but VPC Flow Logs are irrelevant to bucket permissions. Therefore, enabling VPC Flow Logs would provide no protection over who can access the S3 bucket.
✓
Apply an S3 bucket policy that restricts access to specific IAM users or roles.
Why this is correct
An S3 bucket policy is a resource-based policy attached directly to the bucket, and it can specify which IAM users or roles are permitted to perform actions such as s3:GetObject or s3:PutObject. Since the policy is evaluated against the principal, action, resource, and conditions, it can restrict access to only specific AWS identities while denying all other principals. This is a native, effective way to protect the bucket and is the recommended resource-based control for enforcing such restrictions.
✓
Use IAM policies to grant permissions to users and roles.
Why this is correct
IAM policies are identity-based policies that attach to IAM users, roles, or groups and explicitly grant permissions to perform S3 actions on specific buckets and objects. When a principal calls an S3 API, the effective permission is the intersection of their identity-based policy and any resource-based policies — both must allow the action (unless a deny overrides). By attaching restrictive IAM policies that grant only the required S3 actions to known principals, an engineer can control access without modifying the bucket's own policy, making this a valid alternative for protecting the bucket.
✗
Enable S3 object ACLs.
Why it's wrong here
S3 object ACLs are a legacy access-control mechanism that uses canonical user IDs or predefined groups rather than IAM roles, making them difficult to map to modern identity models. ACLs are also independent of bucket policies and IAM policies, which creates confusion and increases the risk of unintended public exposure. In addition, newer S3 capability such as Object Ownership and Block Public Access diminishes reliance on ACLs; AWS strongly recommends using IAM policies and bucket policies instead, so enabling ACLs is not a secure way to restrict access.

Visual reference

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

SCS-C02 Infrastructure Security Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question