← SCS-C02·Amazon Web Services

SCS-C02 Data Protection Practice Question

A company wants to protect sensitive data stored in S3 from being accessed by unauthorized users. Which TWO actions should be taken? (Choose two.)

⚠ Common exam trap

The trap is confusing encryption with access control; candidates may think enabling default encryption prevents unauthorized access, but it only protects data at rest, not from authorized users with excessive permissions.

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

✓

Use IAM policies to restrict access to the bucket.

Option A is correct because IAM policies define which principals (users, roles, groups) can perform which S3 actions (such as s3:GetObject or s3:PutObject) on specific bucket or object ARNs, directly controlling authorized access to sensitive data. Option D is correct because enabling S3 Block Public Access at the account level applies account-wide safeguards that reject bucket policies or ACLs granting public access, preventing accidental exposure of sensitive objects to anonymous users. Option B is not correct because S3 Versioning only preserves multiple object versions for recovery and does not by itself prevent unauthorized access. Option C is not correct because default encryption protects data at rest but does not stop an authorized-but-malicious or improperly permissioned principal from reading the data. Option E is not correct because MFA Delete only requires multi-factor authentication for permanently deleting object versions or changing versioning state, which is a deletion control rather than an access control.

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 IAM policies to restrict access to the bucket.
Why this is correct
IAM policies are the primary identity-based access control in AWS. They allow you to grant specific principals, such as IAM users or roles, explicit Allow or Deny permissions for S3 actions on a given bucket and its objects. When combined with resource-based bucket policies, IAM enables fine-grained authorization, such as requiring s3:GetObject only for certain prefixes, which directly prevents unauthorized access to sensitive data.
✗
Enable S3 Versioning.
Why it's wrong here
S3 Versioning creates and preserves multiple versions of each object, so an accidental overwrite or delete can be rolled back by reverting to an earlier version. It is a data-availability and durability feature, not a security boundary, and it does not stop an authenticated user with s3:GetObject permission from reading sensitive content. In fact, versioning can inadvertently enlarge the attack surface because older deleted versions remain retrievable if the principal has access to them.
✗
Enable default encryption on all S3 buckets.
Why it's wrong here
Default encryption protects objects at rest by automatically applying SSE-S3 or SSE-KMS when an object is uploaded. However, encryption is not a substitute for access control: it only defends against physical media theft or certain network-based attacks, and it does not restrict who may call s3:GetObject if the appropriate IAM/bucket permissions are in place. Even with encryption, a user who has the necessary permissions—including KMS decrypt permissions when using SSE-KMS—can still read the data, so misconfigured authorization leaves sensitive data exposed.
✓
Enable S3 Block Public Access at the account level.
Why this is correct
S3 Block Public Access is a centralized guardrail at the account or bucket level that overrides bucket policies and object ACLs that would allow public access. It effectively shuts down the most common cause of S3 data exposure—an overly permissive "Principal":"*" bucket policy—but it does not manage access for users within the organization. To protect sensitive data from unauthorized internal principals, you still need IAM policies or bucket policies that explicitly Deny access.
✗
Enable MFA Delete on the bucket.
Why it's wrong here
MFA Delete forces an authenticated multi-factor authentication challenge before a versioned object version can be permanently deleted or before versioning is suspended. This helps prevent accidental or malicious deletion by someone who has compromised AWS credentials, but it does not in any way stop unauthorized read access or listing of sensitive objects. It is an integrity and availability safeguard, not an authorization control for data confidentiality.

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 Data Protection Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question