Most DOP-C02 candidates can already write an EventBridge rule: match an event pattern, fan out to a Lambda or SNS topic, done. That gets you through the basic “how do I react to a GuardDuty finding” scenario. But the exam increasingly frames event-driven questions around the harder parts of EventBridge — the point-to-point integrations you used to hand-code, the reliability controls that keep events from being silently dropped, the way you call a third-party system without a glue function, and the scheduling service that quietly replaced cron on an EC2 box.
This guide covers the advanced EventBridge surface: Pipes, input transformers, API destinations, retry policies and dead-letter queues, archive and replay, and EventBridge Scheduler. If you need the foundation first — event buses, rules, event patterns, targets, and auto-remediation wiring — the DOP-C02 incident and event response guide covers that in depth, and this article deliberately does not re-teach it. Here we pick up where “rules and targets” leaves off, which is exactly where the harder exam questions live.
Where These Features Fit on the DOP-C02 Blueprint
Event-driven building blocks are not confined to one domain. They show up wherever the exam asks you to automate a pipeline, integrate two systems, or make a workflow resilient:
| Domain | Where advanced EventBridge appears |
|---|---|
| SDLC Automation | Triggering and gluing pipeline stages; integrating build/deploy events with external tools via API destinations |
| Configuration Management & IaC | Reacting to Config compliance changes; scheduled drift and compliance sweeps with Scheduler |
| Resilient Cloud Solutions | Retry policies, DLQs, and archive/replay so no event is lost or unrecoverable |
| Monitoring & Logging | Routing and reshaping events into observability and ticketing systems |
| Incident & Event Response | Event-driven remediation (covered in the linked guide) |
The mental model the exam rewards: EventBridge is not just a router — it is an integration and reliability layer. When a scenario says “without writing custom code,” “without managing a server,” or “without losing events,” it is usually pointing at one of the features below.
EventBridge Pipes: Point-to-Point Integration Without the Glue Lambda
The classic anti-pattern the exam loves to correct is this: an SQS queue (or a Kinesis / DynamoDB stream) needs to feed some target, so you write a Lambda that polls the source, maybe filters or reshapes the message, and forwards it. That Lambda is undifferentiated plumbing — code you have to test, deploy, monitor, and pay for.
Amazon EventBridge Pipes replaces that Lambda with a managed point-to-point integration. A pipe has up to four stages:
Source → Filter (optional) → Enrichment (optional) → Target- Source (polling-based): Amazon SQS, Kinesis Data Streams, DynamoDB Streams, Amazon MQ (ActiveMQ / RabbitMQ), Amazon MSK, and self-managed Apache Kafka.
- Filter (optional): the same event-pattern syntax you already know from rules. Events that don’t match are dropped before enrichment and target, so you don’t pay enrichment or target costs for events you don’t care about.
- Enrichment (optional, synchronous request/response): call a Lambda function, a Step Functions Express workflow, an API Gateway endpoint, or an EventBridge API destination to augment the event — for example, look up customer details to attach to an order event.
- Target: Lambda, Step Functions, SNS, SQS, Kinesis, an EventBridge event bus, API Gateway, an API destination, ECS tasks, and many more.
A minimal pipe from an SQS queue to a Step Functions state machine, filtering to only high-priority messages:
aws pipes create-pipe \
--name orders-to-workflow \
--role-arn arn:aws:iam::111122223333:role/pipe-role \
--source arn:aws:sqs:us-east-1:111122223333:orders \
--source-parameters '{"FilterCriteria":{"Filters":[{"Pattern":"{\"body\":{\"priority\":[\"high\"]}}"}]}}' \
--target arn:aws:states:us-east-1:111122223333:stateMachine:process-orderPipes vs a Lambda event source mapping (ESM) is a common trap. Both can poll SQS/Kinesis/DynamoDB Streams and invoke a Lambda. The difference:
| Lambda event source mapping | EventBridge Pipes | |
|---|---|---|
| Target | Lambda only | Many targets (Step Functions, SNS, SQS, API destination, EventBridge bus, ECS…) |
| Filtering | Yes (event filtering) | Yes (same syntax) |
| Enrichment | No — you code it in the function | Built-in enrichment stage |
| Code required | The Lambda itself | None for the integration |
Rule of thumb for the exam: if the scenario says “connect a queue/stream to a target without writing code,” or needs enrichment before delivery, or the target is not Lambda, reach for Pipes. If it’s a stream feeding a Lambda you’re writing anyway, an event source mapping is fine.
Input Transformers: Reshape the Event Before It Lands
By default, a target receives the entire matched event. That’s rarely what a human-facing target (an SNS SMS, a Slack webhook, a ticketing system) actually wants. Input transformers let you pull specific fields out of the event with input paths and drop them into a plain-text or JSON input template.
For example, turning a raw EC2 state-change event into a readable alert:
{
"InputPathsMap": {
"instance": "$.detail.instance-id",
"state": "$.detail.state",
"time": "$.time"
},
"InputTemplate": "\"Instance <instance> entered state <state> at <time>\""
}The target now receives Instance i-0abc... entered state stopped at 2026-09-28T... instead of a nested JSON blob. Input transformers work on rule targets and on Pipes targets. On the exam, the cue is “send a custom / simplified payload” or “the downstream system expects a specific format” — that’s a transformer, not a Lambda.
API Destinations: Call Third-Party Systems Without a Function
When an event needs to reach an external HTTP endpoint — PagerDuty, Slack, Jira, Datadog, a partner webhook, or your own on-prem API behind a public endpoint — you don’t need a Lambda to make the call. API destinations are EventBridge targets that are HTTPS endpoints, backed by a connection that stores the credentials.
- A connection holds the auth configuration — Basic, API key, or OAuth client-credentials — and EventBridge stores those secrets in AWS Secrets Manager and handles OAuth token refresh for you.
- The API destination references the connection, the endpoint URL, and the HTTP method.
- You can set an invocation rate limit (requests per second) so EventBridge doesn’t overwhelm a fragile downstream API.
- Combine with an input transformer to shape the request body the third party expects.
This is the exam’s answer to “deliver events to a SaaS/third-party endpoint with managed authentication and rate limiting, without maintaining custom integration code.” If you see a hand-rolled Lambda calling a webhook and storing an API token in an environment variable, the better answer is almost always an API destination with a connection.
Reliability: Retry Policies, Dead-Letter Queues, and Archive/Replay
The Resilient Cloud Solutions domain cares about one thing here: an event must not vanish because a target was briefly unavailable, and you must be able to recover. EventBridge gives you three controls.
Target retry policy
When a target invocation fails, EventBridge retries with exponential backoff. Two parameters bound that behavior:
MaximumRetryAttempts— how many times to retry (up to 185).MaximumEventAgeInSeconds— how long an event is eligible for retry (60 seconds up to 24 hours; the default is 24 hours).
Retries stop when either limit is hit.
Dead-letter queue (DLQ)
Attach an SQS dead-letter queue to a rule’s target. Events that exhaust their retries land in the DLQ instead of being discarded, so you can inspect, alarm on, and reprocess them:
aws events put-targets --rule my-rule --targets '[{
"Id": "1",
"Arn": "arn:aws:lambda:us-east-1:111122223333:function:process",
"DeadLetterConfig": {"Arn": "arn:aws:sqs:us-east-1:111122223333:eb-dlq"},
"RetryPolicy": {"MaximumRetryAttempts": 4, "MaximumEventAgeInSeconds": 3600}
}]'Exam cue: “ensure failed event deliveries are not lost / can be investigated later” → DLQ on the target. This is the same instinct you’d apply to asynchronous Lambda and SQS consumers.
Archive and replay
A retry policy protects against transient failures. Archive and replay protects against your own bugs. You can create an archive on an event bus — optionally filtered by an event pattern — with a retention period (or indefinite). Every matching event is durably stored. Later, if you shipped a broken consumer or want to seed a brand-new one, you replay archived events back onto the bus over a chosen time range; they flow through the matching rules again.
Points the exam tends to probe:
- Replay lets you reprocess historical events after fixing a bug or adding a new consumer — you are not limited to events that happen from now on.
- Replayed events are re-evaluated by rules; ordering is not guaranteed.
- Archive is scoped to a bus, and you choose what to capture with a pattern.
“We deployed a fix and need to reprocess the events we mishandled last Tuesday” is the archetypal archive/replay scenario.
EventBridge Scheduler: Serverless Scheduling at Scale
For years, the way to run something on a schedule was a scheduled rule (cron() / rate()) on the default event bus. That still works, but Amazon EventBridge Scheduler is a separate, purpose-built service for scheduled invocations, and it is what modern DOP scenarios expect.
What Scheduler adds over a scheduled rule:
| Capability | Scheduled rule | EventBridge Scheduler |
|---|---|---|
One-time (at()) schedules | No | Yes (and can auto-delete after running) |
Recurring (rate() / cron()) | Yes | Yes |
| Time zones & daylight saving | UTC only | Yes — cron in a local time zone |
| Flexible time windows (jitter) | No | Yes — spread invocations to avoid a thundering herd |
| Targets | EventBridge targets | Universal target — ~270+ services / 6000+ API actions |
| Built-in retries + DLQ | Via rule target config | Yes, per schedule |
| Scale | Bounded by bus rule quotas | Millions of schedules |
A one-time schedule that fires a Lambda once, in a specific time zone, and deletes itself afterward:
aws scheduler create-schedule \
--name send-reminder \
--schedule-expression "at(2026-12-01T09:00:00)" \
--schedule-expression-timezone "America/New_York" \
--flexible-time-window '{"Mode":"OFF"}' \
--action-after-completion DELETE \
--target '{"Arn":"arn:aws:lambda:us-east-1:111122223333:function:reminder","RoleArn":"arn:aws:iam::111122223333:role/scheduler-role"}'Each schedule has its own execution role, can be organized into schedule groups (with tags), and supports a flexible time window so thousands of schedules due at the top of the hour don’t all fire at exactly :00.
Exam decision guide:
- “Run millions of per-customer / per-tenant schedules” → Scheduler.
- “Fire once at a future time” (a one-time reminder, a delayed action) → Scheduler with
at(). - “Cron in the user’s local time zone, DST-aware” → Scheduler.
- A simple recurring sweep already living in an event-driven setup, low scale → a scheduled rule is acceptable, but Scheduler is the modern default.
If the wider “run a job serverlessly on a schedule” comparison against SQS/SNS/Step Functions is what you’re after, the SAA-C03 decoupling and messaging guide frames those trade-offs; here the focus is Scheduler’s DevOps-scale capabilities.
A Quick Word on the Schema Registry
One more feature worth recognizing: the EventBridge schema registry with schema discovery. Turn on discovery for a bus and EventBridge infers the structure of the events flowing through it, stores versioned schemas, and can generate code bindings (Java, Python, TypeScript) so developers get typed objects instead of parsing raw JSON. It’s a developer-experience feature rather than a routing one, but if a question mentions “generate strongly-typed code from events” or “document the events on a bus,” that’s the schema registry.
Putting It Together: a Reference Pattern
A realistic event-driven integration that touches most of these features:
- Orders arrive on an SQS queue.
- An EventBridge Pipe polls the queue, filters to paid orders, enriches each with customer tier from a Lambda, and delivers to a Step Functions workflow.
- The workflow emits a “shipment created” event to a custom event bus.
- A rule on that bus uses an input transformer to build a webhook payload and delivers it to the shipping partner via an API destination (OAuth connection, rate-limited), with a DLQ and a retry policy so no shipment notification is lost.
- An archive on the bus captures all shipment events; when a downstream analytics consumer is added next quarter, you replay the last 90 days to backfill it.
- A nightly reconciliation job runs via EventBridge Scheduler (
cron()in the finance team’s time zone) against a Lambda, with its own retries and DLQ.
No custom polling code, no cron server, no lost events, and full recoverability — which is exactly the architecture the DOP-C02 exam wants you to recognize.
Decision Cheat Sheet
| Scenario language | Reach for |
|---|---|
| Connect a queue/stream to a non-Lambda target, no code | EventBridge Pipes |
| Enrich an event before delivery | Pipes enrichment stage |
| Send a simplified/custom payload to the target | Input transformer |
| Call a SaaS / webhook with managed auth + rate limit | API destination + connection |
| Don’t lose events when a target fails | Retry policy + DLQ |
| Reprocess historical events after a fix | Archive + replay |
| Run millions of schedules / one-time / time-zone-aware | EventBridge Scheduler |
| Simple recurring trigger in an existing bus | Scheduled rule |
| Generate typed code from events on a bus | Schema registry + discovery |
Common Exam Traps
- Pipes vs rules. A rule fans one event out to up to five targets. A pipe connects one source to one target point-to-point, with filtering and enrichment. Don’t use a rule where the scenario is clearly a single source→target integration that needs enrichment.
- Where scheduled work belongs. Modern scheduling (one-time, time zones, high scale) is Scheduler, not a scheduled rule and definitely not cron on EC2.
- API destinations replace glue Lambdas. A Lambda whose only job is to call an external HTTP endpoint with a stored token is a smell; the better answer is an API destination.
- DLQ ≠ retry. Retries handle transient failures; the DLQ catches what retries can’t. Resilient designs use both.
- Default bus vs custom bus. AWS service events (GuardDuty, Config, Health) arrive on the default bus; custom and partner events use custom buses. This still trips people up even in advanced questions.
Practice on Realistic DOP-C02 Scenarios
Reading about Pipes and Scheduler is not the same as instantly recognizing them under exam pressure, where every option looks plausible. The fastest way to internalize the decision cues is to work through scenario questions that force you to choose between a rule, a pipe, an ESM, a scheduled rule, and Scheduler — and then read why the distractors are wrong.
Sailor.sh’s AWS Certified DevOps Engineer - Professional (DOP-C02) mock exam bundle is built exactly for that: exam-weighted questions across all six domains, with explanations that focus on the “why this and not that” reasoning these event-driven questions demand. Pair it with the DOP-C02 exam guide for the blueprint and the DOP-C02 study plan to sequence your prep.
Frequently Asked Questions
Is EventBridge Pipes the same as an EventBridge rule? No. A rule matches events on a bus and fans out to up to five targets. A pipe is a point-to-point integration from a single polling source (SQS, Kinesis, DynamoDB Streams, MQ, MSK, Kafka) to a single target, with optional filtering and a synchronous enrichment step. Rules route; pipes integrate.
When should I use EventBridge Scheduler instead of a scheduled rule? Use Scheduler for one-time schedules, time-zone- and DST-aware cron, flexible time windows to avoid a thundering herd, very high schedule counts, and when you want per-schedule retries, DLQs, and the universal target. A simple recurring rule already inside an event-driven design can stay a scheduled rule, but Scheduler is the modern default.
What’s the difference between a retry policy and a dead-letter queue? The retry policy controls how many times and for how long EventBridge retries a failed target delivery (up to 185 attempts, up to 24 hours). The DLQ is an SQS queue that captures events that still fail after retries are exhausted, so they can be inspected and reprocessed rather than lost.
Can I reprocess events that already happened? Yes — if you created an archive on the bus. Replaying an archive re-sends stored events over a chosen time range through the bus’s rules, which is how you backfill a new consumer or reprocess after fixing a bug. Replayed events are re-evaluated by rules and are not guaranteed to preserve original ordering.
Do API destinations need a Lambda? No. An API destination delivers events directly to an external HTTPS endpoint. A connection stores the auth (Basic, API key, or OAuth) in Secrets Manager and refreshes OAuth tokens automatically, and you can rate-limit invocations. That removes the glue Lambda entirely.
Does filtering in Pipes save money? Yes. Filter criteria are evaluated before enrichment and the target, so events that don’t match are dropped early and you don’t incur enrichment or target processing for them.
Ready to test whether you can spot the right event-driven pattern on sight? Put these decisions under timed pressure with the DOP-C02 mock exam bundle and turn recognition into reflex before exam day.