EventBridge patterns and operational automation

Exam alignment: DOP-C02 Domain 4 — collection, analysis, detection, and automated monitoring.

Learning objective

Design, implement, and troubleshoot event patterns, AWS Health events, targets, retries, DLQs, idempotency, and cross-account event buses with secure collection, actionable detection, correlation, lifecycle controls, and measured cost.

Professional scenario

A production team has partial telemetry for event patterns, AWS Health events, targets, retries, DLQs, idempotency, and cross-account event buses. During incidents, signals are inconsistent, access is unclear, and operators cannot move reliably from detection to diagnosis and response.

Core concepts

• The lesson focuses on event patterns, AWS Health events, targets, retries, DLQs, idempotency, and cross-account event buses.
• Begin with the operational or user question, not with the AWS service.
• Telemetry identity, fields, dimensions, time, and correlation must be consistent.
• Collection pipelines need permissions, encryption, buffering, retention, failure monitoring, and cleanup.
• Detection requires tested thresholds or models, an owner, context, and a response action.
• Monitoring configuration should be versioned and deployed as code.

Architecture walkthrough

1. Define the service outcome and failure condition.
2. Choose metrics, logs, traces, or events for the question.
3. Define source identity, dimensions, fields, and correlation.
4. Configure collection, encryption, retention, and least-privilege access.
5. Create dashboards, queries, alarms, or automated actions.
6. Generate normal, failing, and missing-data cases.
7. Measure alert quality, query speed, coverage, and cost.

Decision guide

Requirement	Preferred direction	Why
Known numeric condition	Metric and alarm	Fast continuous evaluation
Detailed investigation	Structured logs and queries	Rich event context
Distributed request path	Trace with propagated context	Shows dependencies and latency
AWS configuration change	CloudTrail and AWS Config	Shows API activity and resulting state

Failure modes and troubleshooting

• The producer and consumer use different dimensions or field names.
• KMS, IAM, resource policy, or destination permissions block delivery.
• High-cardinality attributes create cost and query problems.
• Missing data is interpreted incorrectly.
• A dashboard or alarm exists but its action and notification path were never tested.

Security, privacy, and operations

• Exclude secrets, credentials, tokens, and prohibited personal data before ingestion.
• Separate telemetry writers, readers, administrators, and security auditors.
• Protect central archives, KMS keys, subscriptions, and alarm actions.
• Audit changes to retention, encryption, destinations, and monitoring rules.

Hands-on lab

Goal: Build and validate a controlled example for this topic.

Tasks

1. Write the operational question and expected response.
2. Draw the telemetry path from source to storage, query, alarm, and action.
3. Create a minimal implementation or detailed configuration.
4. Introduce one controlled delivery or detection failure.
5. Diagnose the first failed component.
6. Document cost, retention, security, and cleanup.

Validation

• The signal answers the stated operational question.
• Delivery failure is detectable.
• No sensitive or unbounded attribute is collected.
• The response path is tested.

Cost control: Use synthetic data and a narrow scope. Delete test alarms, logs, streams, indexes, functions, and dashboards.

Exam traps

• Collecting every signal without a question.
• Using CPU as the universal health or scaling metric.
• Confusing metric filters, subscription filters, and Logs Insights.
• Assuming encryption alone prevents deletion or unauthorized administration.
• Centralizing telemetry without validating account and Region coverage.

Key takeaways

• event patterns, AWS Health events, targets, retries, DLQs, idempotency, and cross-account event buses.
• Telemetry must be secure, correlated, actionable, and cost controlled.
• Monitoring itself requires monitoring and tests.

Review questions

1. What operational question is being answered?
2. Which telemetry signal is primary?
3. Which identity and correlation fields are required?
4. Which permission layers affect delivery?
5. What is the retention and cost model?
6. What does missing data mean?
7. What action follows detection?
8. How is the design tested?

Answers

1. The explicit user, service, audit, or operational condition.
2. The signal that detects or explains that condition most directly.
3. Service, environment, version, time, request or trace context, and safe resource identity.
4. IAM, resource policies, KMS policies, destination permissions, and organization controls.
5. A documented lifecycle aligned to investigation, compliance, and budget.
6. It depends on whether the signal is continuously expected or emitted only on events.
7. A notification, runbook, ticket, scaling action, recovery action, or controlled automation.
8. With synthetic normal, failure, missing-data, permission, and delivery tests.