DOP-C02 - Incident and Event Response (14% of the exam) - Section 5.2

Process events and notify responders using Amazon EventBridge Pipes, Amazon SNS, AWS Chatbot and chat-based operations.

Filter and enrich event streams between sources and targets using Amazon EventBridge Pipes, and deliver alerts to Amazon SNS topics for fan-out notification. Integrate AWS Chatbot with Slack or Microsoft Teams to enable ChatOps, acknowledging and running commands against incidents directly from a chat channel.

Amazon EventBridge PipesAmazon SNSAWS ChatbotChatOps

Practice question for this objective

Free sampleIncident and Event Responsemedium

An operations team wants on-call engineers to run approved diagnostic and remediation commands, such as restarting a service through an AWS Systems Manager Automation runbook, directly from their Slack channel during an incident, without leaving chat or opening the console. The actions must run under a controlled, least-privilege role rather than an engineer's personal credentials. Which approach delivers this chat-based operations capability with the LEAST custom code?

AConfigure AWS Chatbot for the Slack workspace and channel, assign it a channel IAM role scoped to the permitted Automation actions, and apply channel guardrail policies so engineers invoke the runbook through approved chat commands. Correct
BBuild a Slack application backed by an AWS Lambda function behind Amazon API Gateway that parses slash commands, assumes a role, and calls the Systems Manager Automation API on the engineer's behalf.
CCreate an Amazon SNS topic that posts incident alerts into Slack through an email-to-channel forwarder so engineers can read the alert and then run the Automation runbook from the AWS console themselves.
DGrant each on-call engineer a long-lived IAM access key stored in Slack and a shared script that reads the key from a pinned message to call the Systems Manager Automation runbook during incidents.

Use AWS Chatbot with a scoped channel IAM role and guardrails to run approved AWS commands from chat without building a custom Slack integration. AWS Chatbot lets engineers run supported AWS CLI-style commands, including starting Systems Manager Automation runbooks, from a configured Slack channel; the actions execute under the channel IAM role and are bounded by guardrail policies, so chat-based operations stay least privilege and require no bespoke webhook or Lambda code.

Why A is correct: AWS Chatbot natively runs supported AWS commands from Slack under a configured channel IAM role bounded by guardrail policies, so engineers trigger the Automation runbook from chat with least-privilege control and no custom integration code.

Why B is wrong: A custom Slack app and Lambda parser can run the commands, but it is bespoke plumbing the team must build, secure, and maintain, whereas AWS Chatbot delivers the same chat-driven actions as managed configuration.

Why C is wrong: An SNS-to-Slack forwarder only delivers notifications and still sends engineers to the console to act, so it provides no in-chat command execution and fails the requirement to run remediation from Slack.

Why D is wrong: Embedding long-lived keys in chat is a serious security failure and is the opposite of least privilege, so although it technically runs commands it breaks the controlled-role requirement entirely.

See more DOP-C02 practice questions, answers explained.

Exam traps in Incident and Event Response

Answers that look right on this material and are not. Each one is a distractor from a different question in the DOP-C02 bank for this domain.

Tighten the channel IAM role policy to only the actions currently needed and review it on a schedule, trusting the review cycle to keep the role from drifting beyond the approved set of actions.
Why it is wrong: Scoping the role helps, but the role can still be widened later and a review cycle is procedural rather than enforced, so it does not provide the hard permission ceiling the lead requires.
Send every event through the enrichment step first to add the account metadata, then place a filter after enrichment that drops the low-value events just before the SNS target is invoked.
Why it is wrong: Filtering after enrichment still pays to enrich every event, including the ones that are discarded, which wastes the enrichment calls the team specifically wants to avoid for low-value events.
Subscribe one AWS Lambda function to the topic that reads the severity attribute of every message and forwards it to the paging queue or the logging function, discarding informational events in its own code.
Why it is wrong: A routing Lambda can branch on severity, but it adds a function the team must invoke for every message and maintain, duplicating logic that SNS message-filtering subscription policies provide natively.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.