SCS-C02 Security Logging and Monitoring Practice Question

Network Topology

Refer to the exhibit. An AWS Config rule checks that S3 buckets deny HTTP requests. The bucket 'my-bucket' is reported as non-compliant. Which change would make the bucket compliant?

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

✓

Add the bucket ARN to the Resource element in the policy.

The bucket policy denies actions when 'aws:SecureTransport' is false (HTTP). However, the policy only applies to the bucket's objects (arn:aws:s3:::my-bucket/*), not to the bucket itself. To deny HTTP requests to the bucket as well, the resource should include the bucket ARN (arn:aws:s3:::my-bucket). The rule likely checks that both bucket and objects are denied.

Answer analysis

Option-by-option breakdown

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

✗
Add a bucket policy that allows only HTTPS requests.
Why it's wrong here
Adding a bucket policy that allows only HTTPS requests does not satisfy the AWS Config rule's requirement for an explicit Deny statement that blocks HTTP. While HTTPS-only Allows would implicitly deny HTTP unless another statement explicitly allows s3:GetObject or other actions, the rule looks for a Deny effect with the aws:SecureTransport condition set to false. Without that Deny, any existing Allow statement granting access regardless of transport would still permit HTTP requests, so the bucket remains non-compliant.
✗
Change the Effect to Allow.
Why it's wrong here
Changing the Effect from Deny to Allow would directly contradict the required behavior: the AWS Config rule s3-bucket-ssl-requests-only expects a Deny statement that blocks requests when aws:SecureTransport is false. An Allow effect would not block HTTP; instead it would explicitly permit it, making the bucket even more permissive. The rule specifically validates that there is a statement with Effect set to Deny, so changing it to Allow fails the rule's evaluation.
✓
Add the bucket ARN to the Resource element in the policy.
Why this is correct
The current policy only lists the object ARN (arn:aws:s3:::bucket/*) in the Resource element, so the Deny statement applies to object-level operations like s3:GetObject and s3:PutObject. To also block bucket-level actions such as s3:ListBucket, the Resource must include the bucket ARN itself (arn:aws:s3:::bucket). Adding the bucket ARN (without the trailing /*) ensures both the bucket and its objects are covered by the Deny, satisfying the rule's requirement for bucket-level HTTP denial.
✗
Remove the Condition element from the policy.
Why it's wrong here
Removing the Condition element from the policy would turn the statement into an unconditional Deny on the specified resources, blocking all requests regardless of whether they use HTTP or HTTPS. This would severely break access because even HTTPS requests would be denied, making the bucket unusable for legitimate clients. The aws:SecureTransport condition is essential; it restricts the Deny to only HTTP requests while allowing HTTPS traffic.

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

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question