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 extend event-driven architectures without changing deployed Lambda functions. In production, this is about knowing exactly how AWS services like SNS can be used to fan out S3 event notifications to multiple consumers cleanly and efficiently. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
A technology firm called StreamWave built an audio transcription service where audio files are uploaded to an Amazon S3 bucket. Currently, an AWS Lambda function is triggered by S3 event notifications to process each audio file. StreamWave wants to evolve the architecture so that different business units can independently receive notifications about their files. Each business unit already owns its own Amazon Simple Queue Service (SQS) queue. The company wants to publish the file location to each queue for the respective department without modifying the existing Lambda function’s code.
The Requirement: #
Enable per-department notifications of new audio files uploaded to S3 by sending the file details to each department’s existing SQS queue, without changing the Lambda function code.
The Options #
- A) Configure the S3 bucket to send event notifications to an Amazon Simple Notification Service (SNS) topic. Subscribe each department’s SQS queue to the SNS topic. Configure subscription filter policies.
- B) Update the Lambda function to write the file location to a single shared SQS queue. Configure that shared SQS queue to forward messages to each department’s individual SQS queue.
- C) Update the Lambda function code to send the file location to each department’s SQS queue directly.
- D) Configure the S3 bucket to send event notifications directly to each department’s SQS queue.
Google adsense #
leave a comment:
Correct Answer #
A
Quick Insight: The Developer Imperative #
- AWS Lambda currently processes files but you must not touch the code.
- S3 can send event notifications to SNS directly, which supports multiple fan-out subscribers.
- Subscribing multiple SQS queues to a single SNS topic enables clean decoupling and scalable messaging.
- Subscription filter policies allow selective delivery if needed.
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 #
Option A leverages AWS SNS as a fan-out message broker. The S3 bucket’s event notifications are sent to an SNS topic. Each department’s SQS queue subscribes to this SNS topic, enabling the S3 event to propagate to multiple queues without any code changes to the Lambda function. This aligns perfectly with the requirement because the Lambda function remains untouched. You also gain flexibility by using SNS subscription filter policies to control which messages go to which department’s queues if needed.
- No changes to Lambda code are required.
- SNS natively supports multiple subscribers, including SQS.
- Decouples event notification publishing from downstream consumers.
- Optimal for highly scalable serverless event fan-out.
The Trap (Distractor Analysis): #
- Why not Option B? While technically possible, it requires modifying Lambda code to write to a shared queue, plus added complexity to forward messages to individual department queues. This violates the no Lambda code changes rule.
- Why not Option C? Directly updating the Lambda function code contradicts the explicit requirement to avoid Lambda code changes.
- Why not Option D? S3 event notifications cannot natively send to multiple queues unless using SNS. S3 supports direct event delivery only to one SQS queue per event type. Also, multiple SQS notifications from one bucket are not practical without SNS as a broker.
The Technical Blueprint #
B) For Developer (Code/CLI Snippet):
Example CLI commands to create SNS topic, subscribe multiple SQS queues, and configure S3 bucket notification:
# Create SNS topic
aws sns create-topic --name audio-files-topic
# Subscribe SQS queues to SNS topic (repeat per department queue)
aws sns subscribe --topic-arn arn:aws:sns:region:account-id:audio-files-topic --protocol sqs --notification-endpoint <SQS-Queue-ARN-DeptA>
aws sns subscribe --topic-arn arn:aws:sns:region:account-id:audio-files-topic --protocol sqs --notification-endpoint <SQS-Queue-ARN-DeptB>
# Update S3 bucket notification to SNS topic
aws s3api put-bucket-notification-configuration --bucket streamwave-audio-bucket --notification-configuration file://notification.json
Contents of notification.json:
{
"TopicConfigurations": [
{
"Id": "AudioFileUpload",
"TopicArn": "arn:aws:sns:region:account-id:audio-files-topic",
"Events": ["s3:ObjectCreated:*"]
}
]
}
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Low (Use SNS as broker) | Low latency, scalable | Fan-out to multiple queues without Lambda code changes |
| B | Medium (Lambda + forwarding) | Added latency due to forwarding | Requires code changes, increased complexity |
| C | High (Code change) | Immediate delivery | Violates no Lambda code change requirement |
| D | N/A (S3 limit) | Not feasible | S3 cannot fan out to multiple SQS without SNS |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick SNS when you see multiple SQS queues needing the same event notification with no Lambda code change.
Real World #
In real-world architectures, event fan-out using SNS is the industry-standard pattern for decoupling publisher and multiple subscribers, especially in event-driven, serverless applications.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.