SCS-C02 Threat Detection and Incident Response Practice Question

A company's security team wants to detect unauthorized S3 bucket access attempts in real time. Which service should they use to generate alerts when an IAM user attempts to access a bucket without proper permissions?

⚠ Common exam trap

It's easy for candidates to choose Amazon GuardDuty because it is associated with threat detection, but they overlook that GuardDuty does not provide real-time, per-user unauthorized access alerts for S3; instead, CloudTrail with CloudWatch alarms directly captures the specific API error event needed for this use case.

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

✓

AWS CloudTrail with CloudWatch alarms

AWS CloudTrail logs all API calls made to S3, including access denied errors. By creating a CloudWatch alarm on the `S3 AccessDenied` event in CloudTrail logs, the security team can receive real-time alerts when an IAM user attempts to access a bucket without proper permissions. This approach directly captures the unauthorized attempt at the API level, enabling immediate detection.

Answer analysis

Option-by-option breakdown

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

✗
Amazon GuardDuty
Why it's wrong here
Amazon GuardDuty is a threat detection service that uses machine learning and anomaly detection across CloudTrail logs, VPC Flow Logs, and DNS logs. It can identify suspicious patterns of unauthorized S3 access, but it operates as a finding-generation service rather than a per-request alarm system. Findings are produced after correlation and analysis, so there is an inherent delay, and GuardDuty cannot be configured to trigger immediate CloudWatch alarms on individual API error codes like AccessDenied. Therefore, it does not provide the real-time, API-call-level detection that CloudTrail with CloudWatch metric filters offers.
✓
AWS CloudTrail with CloudWatch alarms
Why this is correct
AWS CloudTrail records all S3 API requests as event history, and by enabling data events, it captures object-level operations such as GetObject and PutObject. By delivering these events to CloudWatch Logs, you can create metric filters that match S3 error responses such as AccessDenied (403) or AuthorizationError, and then attach a CloudWatch alarm to trigger SNS notifications. Because CloudTrail pushes events to CloudWatch Logs near real time, it enables immediate detection of unauthorized access attempts. This makes it the most suitable option for real-time alerting on actual access denials.
✗
S3 server access logs
Why it's wrong here
S3 server access logs provide detailed records of requests made to a bucket, including requester, bucket name, request ID, and HTTP status. However, these logs are delivered on a best-effort basis, typically in batches with delays ranging from several minutes to hours, so they cannot drive real-time alarms. They are stored as objects in a destination bucket and require separate log processing and alerting logic; there is no native integration with CloudWatch for immediate threshold-based alarms. Consequently, they are useful for audit forensics but not for immediate unauthorized access detection.
✗
AWS Config
Why it's wrong here
AWS Config records configuration changes to AWS resources, such as modifications to S3 bucket policies, lifecycle rules, or encryption settings, and can evaluate them against compliance rules. It does not log individual API calls or object-level access events like GetObject or PutObject, so unauthorized access attempts that do not change configuration go completely undetected. While AWS Config can alert you if a bucket policy becomes public, it cannot tell you that a specific user unsuccessfully accessed an object. Thus it is a configuration governance tool, not an access monitoring tool for S3 operations.

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 Threat Detection and Incident Response Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question