DOP-C02 Incident and Event Response Practice Question

A company uses AWS Systems Manager Patch Manager to patch its EC2 instances. After a patch window, some instances report a 'Failed' status. The DevOps engineer needs to investigate the cause. Which actions should be taken? (Choose three.)

⚠ Common exam trap

The trap is selecting CloudTrail or AWS Config because they sound like auditing tools — but CloudTrail only records API calls and Config only records configuration state, neither of which contains the patch execution error details needed to diagnose failures.

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

✓

Check the S3 bucket where Patch Manager logs are stored for detailed error messages.

Option A is correct because Patch Manager stores detailed patch execution logs, including error messages for failed patching operations, in an S3 bucket (configured as the patch log destination), which is the primary place to inspect granular failure reasons. Option B is correct because the Patch Manager dashboard in Systems Manager shows per-instance and per-patch compliance status, letting the engineer identify exactly which patches failed and on which instances. Option D is correct because patching is executed by the SSM Agent via RunCommand; if the agent is stopped, outdated, or unable to communicate with the Systems Manager endpoints, the patch operation will fail, so verifying the agent is running and current is a key troubleshooting step. Option C is not the right focus because CloudTrail records the RunCommand API calls for auditing and API-level errors, but it does not contain the patch-level failure details needed to diagnose why a patch failed. Option E is not appropriate because AWS Config tracks resource configuration changes and compliance rules, not the execution details or error messages of Patch Manager patch jobs.

Answer analysis

Option-by-option breakdown

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

✓
Check the S3 bucket where Patch Manager logs are stored for detailed error messages.
Why this is correct
Patch Manager can be configured to write command output to an S3 bucket, either through the Systems Manager settings or per Run Command invocation. These logs capture the full stdout/stderr from the patching process, including detailed error messages, exit codes, and failures from the SSM Agent or patch installation tools. Therefore, checking the S3 bucket is the primary way to obtain the specific reason a patch failed on an instance.
✓
Use the Systems Manager Patch Manager dashboard to view the compliance status for each patch.
Why this is correct
The Patch Manager dashboard, part of the Systems Manager console, provides a compliance report that shows the status of each patch (e.g., Installed, Missing, Failed) per instance and per patch. This aggregated view lets you identify which patches specifically failed to install, helping narrow down the affected patches. However, it does not provide the underlying error message for the failure; it only shows the compliance state, so it's a valid but limited troubleshooting step.
✗
Review CloudTrail logs for the RunCommand API calls.
Why it's wrong here
CloudTrail logs the API calls made to Systems Manager, such as SendCommand and GetCommandInvocation, capturing the action, caller, and request parameters. However, CloudTrail does not contain the command output or patch-specific error messages; those are stored in the SSM Agent logs or the S3 output bucket. Thus, reviewing CloudTrail only tells you that a RunCommand API was invoked, not why a patch failed.
✓
Verify that the SSM Agent is running and up to date on the failed instances.
Why this is correct
The SSM Agent is the component that executes Patch Manager operations on an instance. If the agent is not running, is stopped, or is an outdated version that does not support the required patching capabilities, the patching operation will fail immediately. Verifying that the agent is in a healthy, running state and up to date is a fundamental prerequisite check before attempting patch troubleshooting.
✗
Use AWS Config to check the configuration history of the instances.
Why it's wrong here
AWS Config tracks resource configuration changes and can evaluate compliance against rules, such as whether an instance is patched according to a patch baseline. However, it only records the state and configuration history; it does not capture the detailed error messages from a failed patch installation. So AWS Config might indicate that an instance is non-compliant, but it cannot explain why the patch failed, making it ineffective for detailed error investigation.

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

DOP-C02 Incident and Event Response Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question