SCS-C02 Threat Detection and Incident Response Practice Question
A security engineer is investigating a compromised IAM user whose access key was leaked. The engineer uses the AWS CLI to review CloudTrail event history but notices that recent management events performed by the compromised access key are missing. The CloudTrail trail is configured to log management events for all Regions and delivers to an S3 bucket. The engineer needs to determine whether the missing events indicate that the attacker is evading detection or that the engineer is querying the wrong data source. Which action should the engineer take FIRST to confirm the source of the discrepancy?
⚠ Common exam trap
The trap here is assuming that missing CloudTrail events automatically indicate attacker evasion, when a common cause is failed log delivery due to S3 bucket policy, KMS key policy, or service principal 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
✓
Verify that the CloudTrail trail is logging and that the S3 bucket policy, KMS key policy, and CloudTrail service principal permissions allow the trail to deliver logs, then check the S3 bucket for the expected log file prefix and timestamps.
When CloudTrail events appear missing, the first step is to confirm that the trail is actually delivering logs to its destination. A trail can be enabled yet fail delivery because the S3 bucket policy, KMS key policy, or CloudTrail service principal lacks required permissions, or because the trail was modified. Inspecting the S3 bucket for the expected log file prefix and recent timestamps distinguishes a delivery failure from attacker evasion, and it is faster and more definitive than querying event history or GuardDuty.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Query Amazon GuardDuty findings for the IAM user to see whether GuardDuty recorded the API calls, then correlate the GuardDuty finding timestamps with the CloudTrail event history.
Why it's wrong here
GuardDuty findings are generated from a subset of CloudTrail management and data events and do not provide a complete record of every API call. Absence of a GuardDuty finding does not mean the API calls did not occur, and correlating timestamps cannot confirm whether the trail is delivering logs to S3. This approach conflates threat detection with log integrity verification.
- ✓
Verify that the CloudTrail trail is logging and that the S3 bucket policy, KMS key policy, and CloudTrail service principal permissions allow the trail to deliver logs, then check the S3 bucket for the expected log file prefix and timestamps.
Why this is correct
The trail delivers logs to S3 only if the bucket policy, KMS key policy, and CloudTrail service principal have the required permissions. If delivery fails, events will not appear in S3 even though the trail is enabled. Checking the bucket for the expected prefix and recent timestamps confirms whether the trail is actually delivering, which directly addresses the discrepancy before assuming attacker evasion.
- ✗
Enable AWS CloudTrail Insights on the trail to detect unusual API call rates, then review the Insights events in the S3 bucket for the compromised access key.
Why it's wrong here
CloudTrail Insights detects anomalous API call volumes and error rates, but it does not recover missing management events or verify that the trail is delivering logs. Enabling Insights would not explain why the events are absent from S3 and would add analysis overhead without confirming the underlying delivery issue. It is a detection aid, not a troubleshooting step for missing log delivery.
- ✗
Use the AWS CloudTrail console or the aws cloudtrail lookup-events command to query the last 90 days of event history, since the event history is retained for 90 days and is separate from the trail's S3 delivery.
Why it's wrong here
CloudTrail event history is a separate, account-level data source retained for 90 days, but it only contains management events for the current Region when queried without a Region parameter. Using it does not confirm whether the trail's delivery is complete, and it will not show events if the attacker used a different Region or if the trail is misconfigured. It is a useful check but not the first action to validate trail delivery.
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
Courseiva writes every SCS-C02 question from scratch — 1,205 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
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.