DVA-C02 Development with AWS Services Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Separate AWS accounts for each consumer

  Why it's wrong here

  Separate AWS accounts for each consumer would introduce significant architectural complexity and operational overhead without directly addressing the event filtering requirement. While it provides strong isolation, each consumer account would still need to subscribe to the SNS topic and implement its own filtering logic, either post-delivery or through a separate mechanism. This approach does not inherently filter events at the SNS delivery point, making it an inefficient and overly complex solution for simply receiving specific events.

• ✗

  Lambda code that discards unwanted events after invocation

  Why it's wrong here

  Lambda code that discards unwanted events after invocation is an inefficient approach because it means every event published to the SNS topic would trigger a Lambda function. The function would then consume resources and incur costs for processing and subsequently discarding events that were never needed by that specific consumer. This method fails to prevent the delivery of irrelevant messages, instead shifting the filtering burden and cost to the consumer's compute layer.

• ✓

  SNS subscription filter policies

  Why this is correct

  SNS subscription filter policies are the most direct and efficient solution for this requirement. These policies allow each subscriber to define specific rules based on message attributes or the message body. Only messages that fully match a subscriber's defined filter policy are delivered to that particular endpoint, ensuring consumers receive only the relevant "order events" they need. This prevents unnecessary message delivery and optimizes downstream processing by filtering at the source.

• ✗

  SQS long polling only

  Why it's wrong here

  SQS long polling only improves the efficiency of message retrieval from an SQS queue by reducing empty responses and API calls, but it does not provide any message filtering capabilities. If an SQS queue is subscribed to an SNS topic, it will receive *all* messages published to that topic. Consumers polling the queue, even with long polling enabled, would still need to process and discard unwanted events after retrieval, failing to prevent the delivery of irrelevant messages to the queue itself.

Go deeper

Related to this question