SCS-C02 Management and Security Governance Practice Question

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 S3 event notifications and AWS Lambda

  Why it's wrong here

  S3 event notifications only fire for object-level lifecycle events such as s3:ObjectCreated:Put, s3:ObjectRemoved:Delete, or replication events. They are not generated for IAM, STS, Console, or other service API calls, so they cannot detect unauthorized API calls outside S3 operations. A Lambda function would only react to S3 object events, and an S3 access-denied attempt is not an S3 event notification trigger—that would require parsing S3 server access logs or CloudTrail S3 data events separately. Therefore, this pairing cannot provide account-wide monitoring for unauthorized API calls.

• ✓

  AWS CloudTrail and Amazon CloudWatch Logs with metric filters

  Why this is correct

  CloudTrail records every management and data API call as a JSON log entry containing the requesting IAM principal, the action, and the service, including access-denied errors such as UnauthorizedOperation or AccessDenied. When the trail is configured to deliver to CloudWatch Logs, you can create a metric filter with a pattern that matches specific error codes, and then attach a CloudWatch Alarm to that metric to notify on unauthorized API calls. This creates a deterministic, near-real-time alerting pipeline across the entire AWS account, which is exactly what the security engineer needs.

• ✗

  AWS Config and Amazon SNS

  Why it's wrong here

  AWS Config records resource configuration changes and evaluates them against rules for compliance, but it does not capture the actual API calls that initiated those changes. An unauthorized API call often results in no configuration change because the request is denied, so Config never sees it; even if the call succeeded, Config only reports the resulting state, not the identity or action that caused it. SNS in this pairing would only deliver compliance or configuration-change notifications, making it impossible to alert on unauthorized API calls specifically.

• ✗

  Amazon GuardDuty and AWS CloudTrail

  Why it's wrong here

  GuardDuty does ingest CloudTrail management events alongside VPC Flow Logs and DNS logs, but it uses machine learning and threat intelligence to surface findings only when it deems behavior suspicious. It does not provide a direct, custom query or metric-alarm mechanism tailored to every unauthorized API call—many denied requests will not generate a GuardDuty finding. Simply enabling GuardDuty and CloudTrail together cannot replace the precise CloudWatch Logs metric-filter and alarm pattern needed to deterministically monitor all unauthorized API activity.

Go deeper

Related to this question