Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in how message filtering in SNS differs from creating multiple topics or functions for each client. In production, this is about knowing exactly how to decouple and scale event notifications with minimal code changes and maximum maintainability. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
A technology startup operates a microservices platform that aggregates orders from various third-party vendors. The backend exposes multiple customized APIs through Amazon API Gateway, all backed by a shared AWS Lambda function that processes incoming orders. Each vendor expects to receive real-time updates only about their own orders once processing is complete. The company plans to onboard additional vendors in the future with minimal codebase changes and maintenance overhead.
The Requirement #
Design the notification mechanism so that each vendor receives updates solely about their orders, supporting scalable onboarding and minimizing code modifications.
The Options #
- A) Create a separate Amazon Simple Notification Service (SNS) topic per vendor. Modify the Lambda function to publish results to each vendor’s dedicated SNS topic.
- B) Implement a dedicated Lambda function for each vendor that directly notifies the respective vendor’s service endpoint after order processing.
- C) Create a single SNS topic. Configure the Lambda function to publish messages with vendor-specific attributes. Subscribe each vendor to the topic and apply SNS subscription filter policies based on these attributes.
- D) Create a single SNS topic and subscribe all vendors to it without filtering. Publish all order updates to this single topic.
Google adsense #
leave a comment:
Correct Answer #
C
Quick Insight: The Developer Efficiency Imperative #
The key to scalability here is leveraging Amazon SNS subscription filter policies. This avoids code proliferation and enables event-driven notifications tailored per subscriber using message attributes—a core API Gateway + Lambda eventing pattern crucial for DVA candidates.
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 #
Option C is the most scalable and maintainable approach:
- Single SNS topic: Avoids the complexity and cost of multiple topics.
- Message Attributes: The Lambda function tags each notification with vendor-specific metadata.
- Subscription Filter Policies: Each vendor subscribes with a filter policy that matches only their attribute value, ensuring they receive only relevant notifications without additional Lambda functions or API gateways.
- Minimal code changes: New vendors require only creating new subscriptions with filter policies—no changes in the processing Lambda code.
This pattern leverages the powerful event filtering feature built into SNS subscriptions, making your event-driven architecture clean, extensible, and cost-efficient.
The Trap (Distractor Analysis): #
- Why not A? Creating one SNS topic per partner leads to more infrastructure to manage and code modifications to publish to multiple topics. This increases maintenance overhead and costs.
- Why not B? Multiple Lambda functions multiply deployment complexity and operational overhead, violating the requirement for minimal code changes.
- Why not D? One topic without filtering means all partners receive every message, leading to noisy, irrelevant notifications, and additional filtering responsibility on the vendor side.
The Technical Blueprint #
B) For Developer / SysOps (Code/CLI Snippet):
Publish a message with attributes and create a subscription filter policy example:
import boto3
sns = boto3.client('sns')
response = sns.publish(
TopicArn='arn:aws:sns:us-east-1:123456789012:OrderNotifications',
Message='{"orderId":"1234","status":"processed"}',
MessageAttributes={
'vendor': {
'DataType': 'String',
'StringValue': 'VendorA'
}
}
)
print("Message published, ID:", response['MessageId'])
Example subscription filter policy for VendorA:
{
"vendor": ["VendorA"]
}
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Moderate (multiple SNS topic publishes) | Good but costly and complex | Separate topics for each partner, harder to scale |
| B | High (multiple Lambda codes) | Good but operationally expensive | Separate Lambdas, code duplication |
| C | Low (single topic, filter policies) | Excellent event filtering, cost effective | Ideal for scalable on-demand subscriptions |
| D | Low (single topic, no filtering) | Inefficient - all subscribers get all messages | Not suitable for partner-specific notifications |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick Amazon SNS with message filtering when you see partner-specific notifications with scalability and low code changes.
Real World #
In production, teams often avoid multiple topics or Lambda functions when onboarding several clients. SNS subscription filters provide an elegant, native solution to event routing without extra compute or maintenance.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the DVA-C02 exam.