Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For AWS DVA-C02 candidates, the confusion often lies in how to architect event ingestion to multiple AWS accounts without complicating the source system integration. In production, this is about knowing exactly how to use EventBridge’s cross-account event buses and permission policies to fan out events, all while minimizing operational overhead and avoiding duplications or complex SCM webhook changes. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
CloudSpark Inc. manages an on-premises source control system that must trigger events in the cloud whenever code is pushed. The current integration uses an Amazon API Gateway REST API endpoint to accept webhooks from the SCM system and forwards events to Amazon EventBridge for processing in CloudSpark’s central AWS account. CloudSpark now wants to extend event notifications to multiple AWS accounts that host separate deployment pipelines, without modifying the SCM webhooks or creating multiple webhook endpoints.
The Requirement: #
How can the lead developer enable event distribution so all AWS accounts receive the same events, keeping the SCM integration unchanged?
The Options #
- A) Deploy the API Gateway REST API separately in each AWS account. Use the same custom domain name on all APIs so SCM can use one webhook URL for all accounts.
- B) Deploy the API Gateway REST API in each receiving account. Create a distinct webhook in the SCM for each AWS account.
- C) Grant permissions for the central account’s EventBridge to send events to event buses in the receiving AWS accounts. Configure the existing EventBridge rule’s targets to include the cross-account event buses.
- D) Convert the API Gateway REST API type to HTTP API.
Google adsense #
leave a comment:
Correct Answer #
C
Quick Insight: The Developer Imperative #
Cross-account event routing via EventBridge event buses is the cleanest solution here. It removes the need to change the existing SCM webhook or deploy redundant API Gateway endpoints. Familiarity with
PutEventsAPI permissions and event bus policies is key for success.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option C
The Winning Logic #
This solution leverages Amazon EventBridge’s native multi-account event routing capability by using event bus permissions and cross-account targets. The central AWS account where the API Gateway receives the webhook publishes events on its EventBridge event bus. By granting the necessary IAM resource policies, EventBridge can forward these events to event buses in the receiving AWS accounts. This removes the need to:
- Replicate API Gateway REST APIs across multiple accounts (avoiding operational complexity).
- Change the SCM webhook configuration or create multiple webhooks, which are often costly or impractical to manage.
- Switch API Gateway REST API types—this has no bearing on cross-account event delivery.
The Trap (Distractor Analysis): #
-
Why not A?
Deploying identical API Gateway REST APIs in every account with matching custom domains is not a scalable or easy-to-maintain approach. Domain name mapping also does not guarantee the webhook can target all endpoints concurrently, and the solution ignores the complexity of managing multiple identical APIs. -
Why not B?
This option forces multiple webhook configurations in the SCM, which the requirement explicitly forbids. It multiplies operational overhead and introduces potential synchronization challenges across accounts. -
Why not D?
Changing API Gateway REST API to HTTP API doesn’t solve the fundamental problem of fan-out to multiple AWS accounts and unnecessarily complicates the system. It fails to address multi-account event routing constraints.
The Technical Blueprint #
# Example: Grant permission in receiver account to allow central account EventBridge to put events
aws events put-permission \
--event-bus-name default \
--principal <Central-Account-ID> \
--action events:PutEvents
# Then configure the EventBridge rule in central account to add the remote account’s event bus ARN as a target
aws events put-targets --rule <Rule-Name> \
--targets "Id"="Target1","Arn"="arn:aws:events:<region>:<Receiver-Account-ID>:event-bus/default"
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | High | Low-Medium | Attempts multi-deployment & custom domain usage |
| B | Medium-High | Medium | Multiple SCM webhooks, not allowed by req. |
| C | Medium | High | Native event fan-out with minimal SCM change |
| D | Low | Not Applicable | Irrelevant API type change |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For event fan-out with minimal source changes, always consider EventBridge cross-account event buses.”
Real World #
“In practice, companies embrace EventBridge’s native multi-account support because it dramatically reduces integration overhead and accelerates deployment automation without touching legacy webhook systems.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.