SCS-C02 Security Logging and Monitoring Practice Question
A company uses AWS Config to track resource changes. They notice that a weekly compliance report shows an S3 bucket as non-compliant with a rule that checks for server-side encryption. However, the bucket has default encryption enabled. What is the MOST likely reason for this discrepancy?
⚠ Common exam trap
Many exam-takers confuse default bucket encryption with server-side encryption enforcement, assuming that enabling default encryption automatically satisfies the Config rule, when in fact the rule requires a bucket policy to deny unencrypted uploads.
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
✓
The Config rule checks for SSE on objects, not default bucket encryption.
The AWS Config managed rule `s3-bucket-server-side-encryption-enabled` specifically checks whether the bucket policy enforces server-side encryption on objects uploaded to the bucket, not whether the bucket has default encryption configured. Default encryption only applies to objects that do not have an encryption setting at the time of upload, but the rule evaluates the bucket's policy for a condition that requires SSE for all PUT requests. Therefore, a bucket with default encryption enabled but without a policy enforcing SSE will be reported as non-compliant.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The Config rule checks for SSE on objects, not default bucket encryption.
Why this is correct
The managed AWS Config rule s3-bucket-server-side-encryption-enabled is deliberately designed to verify that an S3 bucket policy requires the x-amz-server-side-encryption header on uploads — it does not inspect the bucket's default encryption configuration. Setting 'Amazon S3 default encryption' only applies SSE to objects uploaded without explicit encryption headers; those headers can be omitted or overridden by the client, so the bucket remains NON_COMPLIANT unless a bucket policy explicitly denies requests lacking the required encryption header. Therefore, seeing a bucket with default encryption flagged as NON_COMPLIANT is the rule's expected behavior, not a misconfiguration of Config.
- ✗
The Config rule was deleted and recreated without re-evaluating existing resources.
Why it's wrong here
Recreating a Config rule — whether by deletion and re-creation or by adjusting its configuration — triggers a new evaluation cycle for all applicable resources in that region, typically within minutes. Additionally, this rule is a periodic rule that runs every 24 hours by default (unless you specify a different frequency), so any newly created or previously skipped resource would be evaluated again soon. Because Config guarantees both initial evaluation on rule creation and recurring periodic evaluations, a deleted and recreated rule is never the reason a bucket remains NON_COMPLIANT.
- ✗
The Config rule is only evaluating resources in a single AWS Region.
Why it's wrong here
This particular managed rule is regional in scope, which means it only evaluates S3 buckets in the same AWS Region where AWS Config is enabled and where the rule is deployed. If the bucket in question resides in the same region as the active Config recorder and the rule, it is included in evaluation; regional scope does not cause a bucket to be skipped. For the scenario described, the bucket is in a region where Config is enabled, so this explanation cannot account for the NON_COMPLIANT result — the rule is evaluating it, just against policy conditions rather than default encryption.
- ✗
The S3 bucket is not tagged with a required tag for the Config rule.
Why it's wrong here
The managed rule s3-bucket-server-side-encryption-enabled has no dependency on S3 tags; it evaluates all S3 buckets in the region unless you explicitly narrow its scope using the optional tagKey and tagValue input parameters. When no tag-based filtering is configured in the rule's JSON input, every bucket is evaluated regardless of whether it has tags, a specific tag key, or any tag value. A missing tag can trigger a NON_COMPLIANT result only for rules that are specifically defined to require certain tags, which is not the case here — so tagging is unrelated to the observed failure.
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
Related to this question
About these practice questions
One of 1,205 original SCS-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SCS-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SCS-C02 exam.