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 decouple event routing from Lambda processing without rewriting function code. In production, this is about knowing exactly how to leverage AWS event routing services (SNS, SQS) to extend functionality while keeping your Lambda functions immutable and stable. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
Skyline Media Solutions processes voice recordings across multiple business units. Whenever a voice file is uploaded to a centralized Amazon S3 bucket, an AWS Lambda function is triggered to perform post-processing. Each business unit needs to consume notifications about their files independently via separate Amazon Simple Queue Service (SQS) queues that already exist. The development team wants to implement this routing without modifying the Lambda function code.
The Requirement: #
Implement a solution so that the location of each new audio file is published separately to each business unit’s SQS queue without changing the existing Lambda function.
The Options #
- A) Configure the S3 bucket to send event notifications to an Amazon Simple Notification Service (SNS) topic. Subscribe each business unit’s SQS queue to the SNS topic. Configure subscription filter policies.
- B) Update the Lambda function code to write the file location to a shared SQS queue, then configure that queue to forward messages to the business unit SQS queues.
- C) Update the Lambda function code to send the file location individually to each business unit’s SQS queue.
- D) Configure the S3 bucket to send event notifications directly to each business unit’s SQS queue.
Google adsense #
leave a comment:
Correct Answer #
A
Quick Insight: The Developer Imperative #
The trick here is to keep Lambda code unchanged while extending event routing capabilities. Using SNS as a fan-out notification broker with subscription filter policies enables independent delivery to multiple SQS queues without any Lambda updates. This preserves code stability and enables specialized, decoupled processing pipelines per business unit.
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 A
The Winning Logic #
- Amazon S3 buckets can send event notifications directly to SNS topics, SQS queues, or Lambda functions.
- By configuring S3 to send notifications to an SNS topic, you get a flexible fan-out pattern—SNS can push messages to multiple subscribers.
- Subscribing each business unit’s SQS queue to the SNS topic enables independent and parallel delivery of notifications.
- Using SNS subscription filter policies allows each queue to receive only the messages relevant to that business unit based on message attributes.
- This approach requires no change to the existing Lambda function triggered by the S3 event; Lambda continues processing as before.
- The solution therefore respects the requirement to keep Lambda code untouched and leverages native AWS services to extend functionality.
The Trap (Distractor Analysis) #
- Option B: Requires changing Lambda code and adds complexity by introducing an additional message forwarding layer (SQS forwarding). This contradicts the requirement to keep Lambda unchanged.
- Option C: Directly updating Lambda to write to multiple queues involves code change and maintenance complexity—against the stated constraint.
- Option D: S3 event configuration allows only one destination per event type, so you cannot natively send the same event to multiple SQS queues. This option won’t meet the requirement.
The Technical Blueprint #
# Example CLI commands to set up SNS topic and subscriptions from S3 event notifications
aws sns create-topic --name voice-files-topic
aws sns subscribe --topic-arn arn:aws:sns:region:account-id:voice-files-topic --protocol sqs --notification-endpoint <BU1-SQS-ARN> --attributes '{"FilterPolicy":"{\"department\":[\"BU1\"]}"}'
aws sns subscribe --topic-arn arn:aws:sns:region:account-id:voice-files-topic --protocol sqs --notification-endpoint <BU2-SQS-ARN> --attributes '{"FilterPolicy":"{\"department\":[\"BU2\"]}"}'
aws s3api put-bucket-notification-configuration --bucket voice-uploads-bucket --notification-configuration \
'{
"TopicConfigurations": [
{
"TopicArn": "arn:aws:sns:region:account-id:voice-files-topic",
"Events": ["s3:ObjectCreated:*"],
"Filter": {
"Key": {
"FilterRules": [
{
"Name": "suffix",
"Value": ".wav"
}
]
}
}
}
]
}'
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Low - SNS + SQS setup | High - native fan-out | Decoupled, scalable multi-target without code changes |
| B | Medium - Lambda code + SQS forwarding | Medium - adds latency | Requires Lambda code change, increased maintenance |
| C | High - Lambda writes to all queues | Medium - Lambda bottleneck possible | Code change needed, less scalable |
| D | Unsupported by S3 | N/A | Not feasible to fan-out directly from S3 to multiple SQS |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the exam, always pick SNS when you see the need to fan out events to multiple, distinct subscribers without changing existing processing functions.”
Real World #
“In practice, using SNS with subscription filtering provides an elegant pub/sub model, reducing coupling and enabling independent scaling & monitoring of downstream processing queues.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.