DOP-C02 Incident and Event Response 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.

• ✗

  Configure VPC Flow Logs to capture traffic to the IAM endpoint.

  Why it's wrong here

  VPC Flow Logs capture metadata about IP traffic—source/destination addresses, ports, and protocols—at the network interface level, but they do not inspect the contents of API requests. While they could confirm that traffic reached the IAM endpoint (iam.amazonaws.com), they cannot reveal the specific IAM action such as AssumeRole or any parameters like role ARN. Consequently, Flow Logs provide no visibility into API activity and cannot be used to detect anomalous role assumption events.

• ✗

  Use S3 event notifications on the CloudTrail bucket for PutObject events.

  Why it's wrong here

  S3 event notifications for PutObject events only signal that a new object (here, a CloudTrail log file) has arrived in the bucket; they do not parse or evaluate the JSON records contained within that object. Detecting anomalous AssumeRole events would require an additional service (e.g., Lambda) to read every log file, extract the relevant events, and apply custom anomaly logic—which is both heavy and non-standard. Amazon's native solution for anomaly detection on CloudTrail data is CloudTrail Insights, not S3 notifications.

• ✗

  Set up a CloudWatch Logs metric filter on the CloudTrail log group for 'AssumeRole' events.

  Why it's wrong here

  CloudWatch Logs metric filters can be configured to count events containing `eventName: AssumeRole`, but this is a manual, static pattern match. You would need to define a specific metric filter and then set arbitrary CloudWatch alarms based on thresholds (e.g., more than 10 events in 5 minutes), which cannot distinguish between normal and anomalous behavior. The filter has no baseline awareness or ML capability, so it will not detect subtle anomalies that deviate from typical usage patterns.

• ✓

  Enable CloudTrail Insights to detect anomalous AssumeRole events.

  Why this is correct

  CloudTrail Insights is the correct choice because it automatically applies machine learning to management events, including IAM AssumeRole, to establish a normal baseline and flag anomalous activity. It requires no manual filter definitions—you simply enable Insights on the trail, and it begins detecting unusual API call rates or error rates, logging them as separate Insights events. This is purpose-built for identifying abnormal role assumption patterns, such as an unexpected spike in AssumeRole calls or a new principal assuming roles outside its normal context.

Go deeper

Related to this question