SCS-C02 Security Logging and Monitoring Practice Question
A company uses AWS CloudTrail and wants to ensure that all log files are encrypted at rest using a customer-managed AWS KMS key. The CloudTrail trail is configured to use a KMS key, but some log files appear to be encrypted with the default Amazon S3 managed key (SSE-S3). What is the most likely cause?
⚠ Common exam trap
It's easy for candidates to assume the S3 bucket's default encryption setting (SSE-S3) overrides the trail's KMS configuration, but in reality, CloudTrail explicitly requests encryption and only falls back to SSE-S3 when the KMS key cannot be used due to permission issues.
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 KMS key policy does not grant CloudTrail permission to use the key.
The most likely cause is that the KMS key policy does not grant CloudTrail the necessary permissions to use the key for encryption. When a CloudTrail trail is configured with a customer-managed KMS key, the key policy must include a statement that allows the CloudTrail service principal (cloudtrail.amazonaws.com) to perform the kms:GenerateDataKey and kms:Decrypt actions. Without these permissions, CloudTrail falls back to encrypting log files with the default Amazon S3 managed key (SSE-S3), resulting in some logs appearing encrypted with SSE-S3 instead of SSE-KMS.
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 KMS key policy does not grant CloudTrail permission to use the key.
Why this is correct
The KMS key policy is the most likely root cause. When a trail is configured with SSE-KMS, CloudTrail must call kms:GenerateDataKey and kms:Decrypt on the customer-managed key to encrypt and decrypt log files. If the key policy does not grant these permissions to the `cloudtrail.amazonaws.com` service principal, CloudTrail cannot use that key and silently falls back to encrypting the log files with SSE-S3, which is exactly the observed behavior. You must add a policy statement that allows CloudTrail to use the key, and you may also need to grant the CloudTrail IAM role the corresponding kms:Decrypt permission.
- ✗
The CloudTrail trail is configured to use SSE-S3 instead of SSE-KMS.
Why it's wrong here
This explanation is incorrect because the trail has already been configured to use SSE-KMS by selecting a customer-managed key in the trail's settings. If the trail were genuinely set to SSE-S3, the user would see the SSE-KMS KMS key ID in the trail configuration, and the problem would be a simple misconfiguration, not a key permission issue. The fact that log files are being encrypted with SSE-S3 doesn't mean the trail is configured that way; it means the KMS encryption request is being rejected and CloudTrail is falling back to S3-managed encryption. Therefore, the trail configuration is not the cause of this encryption behavior.
- ✗
The KMS key is in a different AWS region than the S3 bucket.
Why it's wrong here
The AWS KMS key being in a different region from the Amazon S3 bucket does not prevent CloudTrail from using it. CloudTrail supports using a customer-managed CMK from any AWS region to encrypt log files that are delivered to an S3 bucket in another region. The KMS key is referenced by its ARN and alias, not by any regional dependency for this use case. If encryption were failing, you would see KMS errors such as `InvalidKeyId` or `KMS.KeyUnavailable`, not a silent fallback to SSE-S3, so a regional mismatch is not the likely cause here.
- ✗
The S3 bucket has default encryption set to SSE-S3.
Why it's wrong here
The S3 bucket's default encryption setting does not affect how CloudTrail encrypts the log files it delivers. When CloudTrail writes logs to the bucket, it explicitly applies the encryption mode specified in the trail, either SSE-S3 or SSE-KMS; if SSE-KMS is selected, CloudTrail passes the CMK ARN with each PutObject request. The bucket's default encryption is only applied to objects that don't have a server-side encryption attribute specified at upload time, but CloudTrail always specifies the encryption context and key. Therefore, even if the bucket defaults to SSE-S3, it will not override CloudTrail's configured KMS key.
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.