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.

• ✗

  Manually re-page the on-call engineer with a higher urgency.

  Why it's wrong here

  Manually re-paging the on-call engineer with a higher urgency is a break-glass action, not an automation feature. Incident Manager (SSM) provides automated escalation plans that engage subsequent contacts after a configured timeout, so re-paging by hand introduces human latency and variable reliability. Additionally, 'higher urgency' is not a supported control in Incident Manager's engagement model; you cannot dynamically raise urgency on a single page—you would instead create a new engagement manually. Relying on manual paging defeats the purpose of Incident Manager's built-in, repeatable escalation workflow and cannot be audited as a formal process.

• ✗

  Use Amazon CloudWatch Events to trigger a second SMS if the incident is not resolved within a time frame.

  Why it's wrong here

  Amazon CloudWatch Events (now EventBridge) can route API-driven events, but it cannot directly send an SMS — you would have to point it at an SNS topic that's configured for SMS delivery, which is an extra hop. More importantly, CloudWatch Events is not a scheduler or stateful timer; you would need a separate rule firing on a cron schedule and then correlate it with the incident ID, which is cumbersome and fails to align with Incident Manager's native escalation logic. The native alternative is the response plan's escalation plan, which is time-based and integrated with contact channels (SMS, voice, push). Writing a custom EventBridge rule to 're-page after a timeout' duplicates this functionality with unnecessary complexity and no visibility inside Incident Manager.

• ✗

  Create an AWS Lambda function that checks the incident status and pages the next responder if no action is taken.

  Why it's wrong here

  A custom Lambda function that polls GetIncident and manually pages the next responder is reinventing a core Incident Manager feature. Escalation plans already perform this exact timing logic natively — they wait a specified number of minutes, then automatically trigger the next contact in the plan without custom code. Building Lambda-based polling risks missing state transitions (e.g., acknowledgment vs. resolution), creates IAM and concurrency concerns, and means you must maintain custom code that is not audited by Incident Manager. Moreover, Lambda invocation durations and timeouts are not designed for long-running 'wait-and-check' workflows; you would need Step Functions or DynamoDB TTL timers, which are far less reliable than the managed escalate-on-timeout behavior.

• ✓

  Configure an escalation plan in the response plan that pages a secondary contact after a specified timeout.

  Why this is correct

  An escalation plan is a first-class component of an AWS Systems Manager Incident Manager response plan. You define a total duration (e.g., 10 minutes) and add engagement targets such as individual contacts, chat channels, or a full on-call schedule; if the primary responder does not acknowledge the incident within that window, Incident Manager automatically pages the secondary/next-level contact using the configured contact channels (SMS, voice, mobile push). This is the intended solution because it is fully managed, idempotent, and does not require any custom code or additional AWS services. Escalation plans also support multiple levels, and you can set the engagement duration per target to progressively move up the chain until someone acknowledges.

Go deeper

Related to this question