Exam objective 4.1 asks you to implement incident response plans using AWS services like Lambda and EventBridge. This concept matters because in a real cloud environment, things break constantly — servers stop responding, databases fill up, security alerts fire — and you can’t have a human watching every single metric 24/7. Event-driven automation lets you build systems that respond to problems automatically, fixing common issues in seconds and escalating only the tricky cases to people.
Jump to a section
A simple way to picture Incident Response and Event-Driven Automation
A night security guard at a large warehouse has one main job: keep the place safe. They don’t stand still staring at a blank wall. They walk a route, check doors, and watch for trouble. If they spot a broken window or an open lock, they don’t just write it in a logbook and wait for morning. They act. They call the police. They lock the area down. Then they file a detailed report so the day team knows exactly what happened and what they did about it.
But a good guard doesn’t just react. They also set up systems that work on their own. Motion sensors turn on floodlights when someone walks near the fence. A camera sends an alert to the guard’s phone if it detects movement after hours. The guard doesn’t have to be there flipping switches for every event. The technology triggers itself, and the guard only steps in when something needs a human decision.
Incident response and event-driven automation work exactly like this. The security guard is your IT operations team. The broken window is a system failure, like a server going offline or a database running out of space. The motion sensor and camera are Amazon EventBridge rules and AWS Lambda functions — automated checks that constantly watch for specific events. When an event happens, the automation springs into action: it can restart a service, send a message to a chat room, or spin up a backup server. The human team only gets involved when the situation requires judgment. This keeps things running smoothly, even when nobody is manually watching the systems every second.
To understand incident response and event-driven automation, you first need to understand the problem it solves. In traditional IT, when something went wrong — say a web server crashed — a monitoring tool would eventually notice and send an email or a page to a human operator. That operator would wake up (or pause their coffee), log in, diagnose the issue, and fix it. This process could take 15 minutes, an hour, or longer. Meanwhile, customers saw errors, and the business lost money.
Event-driven automation flips this model. Instead of waiting for a human to react, you define rules in advance: “If this event happens, then automatically run that action.” This is where the two key AWS services come in: Amazon EventBridge and AWS Lambda.
Amazon EventBridge is a serverless event bus. Think of it as a central switchboard that listens for changes — “events” — happening across your AWS account and external services. An event is simply a notification that something occurred: a new file uploaded to S3, a virtual machine (EC2 instance) stopped, a security group rule changed. EventBridge receives these events and matches them against rules you’ve written. If a rule matches, EventBridge delivers the event to a target — usually an AWS Lambda function.
AWS Lambda is a serverless compute service. “Serverless” means you don’t manage or even see the servers running your code. You simply upload your code (written in Python, Node.js, Java, or another supported language) and tell Lambda, “Run this code when this trigger happens.” Lambda executes the code for you, scales automatically if many events arrive at once, and you only pay for the compute time you use. For incident response, a Lambda function might contain the logic to restart a crashed service, take a snapshot of a failing disk, or send a notification to a Slack channel.
So how does this all fit together in an incident response plan? An incident response plan is a predefined set of steps your team will follow when something bad happens. In a manual world, that plan is a document you read and act on. In an automated world, you implement parts of that plan as code. For example:
An EC2 instance (a virtual server in the cloud) becomes unhealthy.
Amazon CloudWatch (the monitoring service) detects the health check failure and publishes an event to EventBridge.
EventBridge has a rule that matches “EC2 instance state change to running” or a custom pattern for “instance health check failed.”
The rule triggers a Lambda function.
The Lambda function automatically attaches a replacement Elastic IP, or starts a fresh EC2 instance from an AMI (Amazon Machine Image — a template for servers), or sends a notification to the operations team with a pre-filled troubleshooting log.
This entire sequence happens in seconds, without any human intervention. The result: your application’s downtime drops from minutes to seconds. The human team gets notified but may not need to act at all, because the automation already fixed the problem.
Event-driven automation also works for proactive responses — not just fixing things after they break. You can set up rules to react to early warning signs. For example:
A disk on a database instance is 80% full. EventBridge captures this metric alarm.
A Lambda function runs to purge old logs or increase the disk size automatically.
The crisis of a full disk (backup failure, database crash) never happens.
For the DOP-C02 exam, you need to understand the exact mechanics: how to write an EventBridge rule, how to pass event data to a Lambda function, how to handle errors (what happens if the Lambda itself fails?), and how to use “dead-letter queues” to capture events that couldn’t be processed. You also need to know that Lambda has a maximum execution time of 15 minutes — if your automation would take longer, you must split the work or use a different service like AWS Step Functions.
A critical concept is the “event-driven architecture” (EDA). In an EDA, services communicate by emitting events rather than by making direct API calls to each other. This decouples services, making your system more resilient: if one service fails, others can still produce and consume events once it recovers. For incident response, this means your automated responders can be built as independent components that don’t depend on the failing service.
The final piece is “runbooks.” A runbook is a set of standardised procedures for handling common incidents. In AWS, you can implement a runbook as a document (AWS Systems Manager Automation) that runs a sequence of steps automatically. But EventBridge + Lambda is often the simpler, faster way to automate the initial response. The exam expects you to know when to use each approach.
Identify the Incident Pattern
First, determine which failures or events need an automated response. This is not every possible failure, only those that are predictable, frequent, and have a standard fix — for example, an EC2 instance failing a health check or a database reaching 90% disk usage. For the DOP-C02 exam, the scenario will clearly describe the incident pattern you must model.
Define the Automation Logic (Lambda Function)
Write the code that will execute the automated response. This Lambda function must be stateless — it shouldn’t rely on local files or in-memory data, because it may be invoked multiple times in parallel. The function reads the event payload from EventBridge, executes the remediation (e.g., restarting an instance, taking a snapshot), and logs the outcome. The exam expects you to reason about what permission policies the function needs.
Create an EventBridge Rule
In the AWS console or via CloudFormation, create a rule that matches the specific event pattern. You define the source service (e.g., AWS/EC2), the event type (e.g., EC2 Instance State-change Notification), and any detail filters (e.g., state equals 'running'). This rule targets the Lambda function you created. Setting the correct pattern is a common exam question — make sure you understand JSON pattern syntax.
Configure Error Handling and Monitoring
Attach a dead-letter queue (DLQ) to the Lambda function using an SQS queue or an SNS topic. If the function fails after automatic retries (Lambda retries asynchronous invocations up to two times), the event is sent to the DLQ so you can analyse it later. Also set up a CloudWatch Alarm that triggers if events land in the DLQ — this indicates your automation itself is broken and needs human attention.
Test the Automation in a Non-Production Environment
Before deploying to production, simulate the event (e.g., manually stop an EC2 instance in a test account) and verify that the Lambda function runs and performs the expected action. Check logs in CloudWatch Logs for errors. The exam scenario will sometimes require you to identify the correct testing procedure or to debug a failing automation by checking the logs.
Deploy and Iterate
After testing, deploy the automation to production. Monitor its behaviour over weeks — review DLQ messages, adjust the rule pattern if false positives occur, and refine the Lambda code to handle edge cases. Incident response automation is never “set and forget”; it requires continuous improvement as new failure modes are discovered.
Let’s walk through a realistic scenario at a mid-sized e-commerce company that runs its website on AWS. The site is built with several microservices — small, independent services that each handle one function (like product search, payments, and user accounts). Each microservice runs on a group of EC2 instances behind an Application Load Balancer (ALB).
One Tuesday afternoon, the payments service starts failing. The root cause: a memory leak in the latest code deployment causes the service to consume all available RAM and crash every few hours. In a traditional setup, a monitoring alert would page the on-call engineer, who would log in, restart the service, and then spend hours debugging. But this company has implemented an incident response plan using EventBridge and Lambda.
Step by step, here is what happens automatically:
The ALB’s health check pings the payments service every 30 seconds. When the service crashes, the health check fails.
CloudWatch Alarm detects the failed health check and changes state from “OK” to “ALARM.”
CloudWatch publishes an alarm event to EventBridge.
EventBridge has a rule that matches “CloudWatch Alarm State Change – payment-svc-health.” The rule targets a Lambda function named AutoRestartPayments.
The Lambda function runs. Its code retrieves the current Auto Scaling group (the group managing the payment service instances). It terminates the unhealthy instance and tells the Auto Scaling group to launch a fresh instance.
The Lambda function also logs the incident to a central logging system (Amazon CloudWatch Logs) and sends a short message to the operations Slack channel: “Payments instance auto-restarted at 14:32 UTC. Check logs for details.”
The entire sequence — from crash to restored service — takes under 90 seconds. Customers may notice a single slow page load but no extended outage.
The on-call engineer reads the Slack message and decides whether deeper investigation is needed. Because the automation fixed the symptom, they can focus on the real problem (the memory leak) without pressure. They later update the runbook to include a step that automatically collects a memory dump from the crashed instance before terminating it, so the developer team can analyse the leak.
This company also uses event-driven automation for other incidents:
When a new code deployment causes error rates to spike, an EventBridge rule triggers a Lambda that rolls back the deployment to the previous version.
When an S3 bucket receives a new file, a Lambda function automatically scans it for malware before the file is made available to users.
When a security group rule is added (a potential misconfiguration), a Lambda function checks it against compliance rules and reverts it if it violates policy.
The IT professional’s role here is not to react manually but to design, test, and maintain these automated responses. They write the Lambda code, create and test the EventBridge rules, and set up alerts for the one thing that still requires human judgment: “should we deploy a permanent fix?” The automation handles the urgent, repetitive work. The professional handles the strategic, creative work.
The DOP-C02 exam tests your ability to design and implement automated incident response using AWS services. Specifically, objective 4.1 looks for four main patterns of questions:
Pattern 1: You are given a scenario describing a failure (e.g., an EC2 instance fails a health check). You must choose the combination of services that automatically restores the service. The correct answer is almost always EventBridge + Lambda. Distractors might suggest using only CloudWatch Alarms (which can only send notifications, not run code) or using direct SNS to Lambda (possible but EventBridge provides richer event filtering).
Pattern 2: You are asked about event filtering and routing. EventBridge can filter events based on the “detail” field of the JSON event. The exam loves to test whether you know exactly which part of the event structure you match. Example: a rule must trigger only for EC2 “Stop” events, not “Terminate” events. You match on “detail-type” : “EC2 Instance State-change Notification” and “detail” : { “state” : “stopping” }.
Pattern 3: You need to choose between Lambda and AWS Step Functions for a long-running or complex response. Lambda has a hard limit of 15 minutes per execution. If the runbook step takes longer, you must use Step Functions, which can orchestrate multiple Lambdas and wait for human approval.
Pattern 4: You must design for reliability and handling errors within the automation itself. The “dead-letter queue” (DLQ) concept is critical. If a Lambda function fails to process an event (e.g., the function code throws an exception), EventBridge can send the failed event to an SQS queue (DLQ) for later analysis. You should also know to configure a DLQ on the Lambda function itself (for asynchronous invocations) to catch events that fail all retry attempts.
Key concepts to memorise:
EventBridge supports two types of buses: default bus (receives events from AWS services), custom event bus (for your own applications), and partner event bus (for SaaS services like Datadog or PagerDuty).
EventBridge rules evaluate events in real time — they do not batche or delay.
Lambda has a “reserved concurrency” setting that limits how many simultaneous executions can happen. This matters for incident response because a flood of events (e.g., 1000 instances failing at once) could overwhelm a Lambda function, causing it to throttle. You might set reserved concurrency to ensure the function can always handle critical events even under load.
Lambda also has a “provisioned concurrency” setting to keep a certain number of execution environments warm to avoid cold starts (the first execution takes longer because the environment must be initialised). For incident response, a cold start delay of a few seconds might be acceptable, but the exam tests your understanding of the trade-off.
Common traps:
Trap: “Use CloudWatch Events” instead of EventBridge. CloudWatch Events is the older name — AWS has rebranded it to EventBridge. The exam may still use the old name in distractors, but the correct answer will refer to EventBridge if it’s a newer question.
Trap: “Polling for events” using Lambda on a schedule. The correct approach is event-driven, not schedule-driven. A scheduled Lambda that checks every minute is less efficient and less timely than an EventBridge rule that reacts instantly.
Trap: Treating Lambda as a single-purpose compute service. In incident response, Lambda can also call other services — it can start an EC2 instance, modify security groups, or send an SES email. The exam tests whether you know Lambda can integrate with many AWS services via the AWS SDK.
Finally, the exam expects you to know the security implications. The Lambda function that responds to incidents must have an IAM role (a set of permissions) that includes only the actions it needs. For example, a function that restarts EC2 instances needs “ec2:StartInstances” and “ec2:StopInstances” — not full administrative access. Adhering to the principle of least privilege is a recurring exam theme.
Event-driven automation reduces mean time to recovery (MTTR) from minutes to seconds by reacting to failures automatically.
Amazon EventBridge is a serverless event bus that routes events from AWS services to targets like Lambda based on user-defined rules.
AWS Lambda runs your code in response to events, scaling automatically and charging only for the compute time consumed.
An incident response plan implemented with EventBridge and Lambda must also include error handling via dead-letter queues (DLQs) to capture failed events.
Lambda has a maximum execution time of 15 minutes; for longer-running automation, use AWS Step Functions to orchestrate multiple Lambda invocations.
You can use EventBridge to route events cross-account and cross-region, enabling centralised incident response for multi-account environments.
The principle of least privilege applies to Lambda execution roles: the function should only have permissions to execute the specific recovery actions it needs.
EventBridge rules use JSON pattern matching to filter events, so you must know the structure of the event (e.g., detail-type, source) to write accurate rules.
These come up on the exam all the time. Here's how to tell them apart.
Amazon EventBridge
Content-based event filtering using JSON patterns.
Built for event-driven architectures with multiple targets (Lambda, Step Functions, SQS).
Can route events across accounts and regions using event buses.
Amazon SNS
Push-based messaging with fan-out to subscribers based on topics.
No content filtering; subscribers receive all messages for a topic.
Primarily used for notifications (email, SMS) and integration with non-AWS services.
AWS Lambda (for automation)
Runs a single function to completion; maximum 15 minutes execution.
Best for short, stateless actions (restart a server, send a notification).
No built-in retry logic for failed steps (must be coded).
AWS Step Functions (for automation)
Orchestrates multiple tasks, including Lambdas, with branching and parallelism.
Supports long-running workflows with pauses for human approval.
Built-in retry, error handling, and state management.
Event-Driven Automation
Reacts instantly (within seconds) to events as they occur.
Lower cost because compute only runs when an event happens.
Requires a service (EventBridge) to capture and route events.
Polling-Based Automation
A scheduled task (e.g., Cron job) checks for issues at fixed intervals.
Wastes resources between checks and may miss transient failures.
Simpler to implement for some legacy systems that don't emit events.
Dead-Letter Queue (DLQ)
Stores events that failed processing after all retries.
Used for debugging and replaying failed automation steps.
Should be monitored via CloudWatch Alarms.
Primary Queue / Event Bus
The main path for event ingestion and processing.
If it fails (e.g., no subscribers), events may be lost (no built-in persistence).
Operates in real time; no built-in storage for undelivered events.
Mistake
Event-driven automation replaces the need for human operators entirely.
Correct
Automation handles known, predictable failures quickly. Humans are still needed for novel problems, strategic decisions, and maintaining the automation code itself.
Marketing from automation vendors often implies full autonomy, but real systems require exceptions, judgment calls, and ongoing maintenance. Beginners overestimate what automation can do on its own.
Mistake
EventBridge and CloudWatch Events are different, independent services that both watch for events.
Correct
Amazon EventBridge is the evolution of CloudWatch Events. The features have been merged. EventBridge offers all the capabilities of CloudWatch Events plus additional features like custom event buses and schema discovery.
AWS renamed the service but kept the old documentation and exam references alive for a while. Many study resources still use the old name, creating confusion.
Mistake
A Lambda function triggered by an event runs within the same account and region as the event source.
Correct
EventBridge can route events across accounts and across regions. You can set up cross-account event buses that allow a central account to receive and process events from multiple accounts.
Most examples in tutorials use a single account, so beginners assume that's the only way. The exam tests multi-account architectures, which is a more advanced but realistic scenario.
Mistake
If an EventBridge rule fails to match an event, the event is lost forever.
Correct
Events that don’t match any rule are simply ignored — they are not stored or archived unless you explicitly archive them. For incident response, this is fine because you only want to react to specific patterns. If you need to reprocess or audit events, you can enable event archiving on the event bus.
People familiar with message queues (like SQS) expect that undelivered messages are kept or returned. Event buses are different — they are purely routing mechanisms, not queues.
Mistake
You need to write a custom EventBridge rule for every single possible event you want to act on.
Correct
You can write a single rule that uses a pattern to match multiple event types. For example, a rule matching all EC2 state changes (stopping, stopped, running, terminated) can trigger one Lambda that handles all of them, using the event details to decide the action.
Beginners often think in terms of one-to-one mapping because that’s how simple tutorials are structured. The exam rewards efficient, generalised designs.
Mistake
Lambda functions used for incident response must always be written in Python.
Correct
Lambda supports multiple programming languages: Node.js, Python, Java, Go, .NET Core, Ruby, and custom runtimes. The exam does not test specific syntax; it tests the architecture and ability to choose the right language for the team's skills.
Python is the most common teaching language, so many beginners assume it’s mandatory. The exam questions describe the requirement (e.g., 'the team uses Go') but do not penalise the choice.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
EventBridge is a rule-based event bus that can filter events by content and route them to multiple targets including Lambda, SQS, and Step Functions. SNS is a pub/sub messaging service that pushes messages to subscribers (Lambda, email, SMS) based on topics, with no content-based filtering. For incident response, EventBridge is preferred because you can write detailed JSON rules to only trigger on specific failures.
Yes, you can. Your Lambda function can examine the event payload to determine which incident occurred and branch accordingly. This saves you from writing many small functions. However, be mindful of the function getting too complex — the exam may test the trade-off between simplicity and maintainability.
The invocation will time out and the function will be terminated. For longer-running tasks, you must either split the work into smaller chunks (multiple Lambda invocations orchestrated by Step Functions) or use a different service like AWS Batch, which can run longer jobs on EC2 instances.
No, you can create a single rule that matches events from multiple services by specifying the 'source' field. For example, a rule that matches "source": ["aws.ec2", "aws.rds"] will catch events from both EC2 and RDS. But you would need to handle both types of event in the same Lambda function, which may make the code more complex.
You can use the EventBridge console's 'Schema Discovery' feature (or look at the AWS documentation for each service's event reference). Also, you can temporarily configure a rule to send events to a test Lambda that logs the full event, then inspect the logs to see the structure.
Yes, but Lambda itself cannot wait for human input — it must exit. The common pattern is for the Lambda function to send a notification to a chat service (Slack) with an interactive button, or to put a message in an SQS queue that triggers an email to an approver. The approval step itself is typically handled by AWS Step Functions, which can pause execution and resume when an approval signal is received.
You've finished Incident Response and Event-Driven Automation. Continue through the DOP-C02 study guide to build a complete picture of the exam.
Done with this chapter?