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.

• ✗

  AWS Config

  Why it's wrong here

  AWS Config is a resource inventory and compliance service that records configuration changes to AWS resources (e.g., security groups, instance types, AMI IDs) and evaluates them against rules. It does not have an agent that captures OS-level runtime state like active processes, nor does it provide a means to execute commands on the instance. Even with the EC2 instance configured for detailed monitoring, Config remains at the infrastructure configuration level, not the guest OS process level. Therefore it cannot answer what process is crashing the instance.

• ✗

  AWS CloudTrail

  Why it's wrong here

  AWS CloudTrail records AWS API calls made by users, roles, or AWS services, capturing who called what, from where, and when. It operates at the control plane level, auditing actions like RunInstances, StopInstances, or AttachVolume, but it never sees inside the guest OS. A process crashing on the instance generates no CloudTrail event, so CloudTrail cannot provide details about running processes or their resource consumption. It is about accountability and security auditing of the AWS API, not OS telemetry.

• ✓

  AWS Systems Manager Run Command

  Why this is correct

  AWS Systems Manager Run Command is part of AWS Systems Manager and lets you remotely and securely execute shell commands or PowerShell scripts on EC2 instances (and on-premises machines) via the SSM Agent. You can run a command like `ps aux` or `Get-Process` to enumerate running processes, capture output, and store it in S3 or CloudWatch Logs. Because the SSM Agent runs inside the instance as a guest process, it has direct access to OS-level state, making it the appropriate service for collecting process-level data. It also supports rate control and error handling for fleet-wide execution.

• ✗

  Amazon CloudWatch

  Why it's wrong here

  Amazon CloudWatch collects and stores metrics such as CPUUtilization, NetworkIn/Out, and DiskRead/Write from the EC2 hypervisor (or from the CloudWatch agent if installed), but by default these are instance-level aggregates, not per-process breakdowns. Even with the unified CloudWatch agent, you must explicitly configure custom metrics for processes, and it doesn't offer an ad-hoc way to list currently running processes on demand. CloudWatch is for monitoring and alerting on trends, not for interactive investigation like running a top command. To answer the alert, you need to query the OS, which CloudWatch doesn't natively do.

Go deeper

Related to this question