DVA-C02 - Troubleshooting and Optimization (18% of the exam) - Section 4.6

Optimise applications using API Gateway and Amazon CloudFront caching and Amazon SNS subscription filter policies to reduce load.

Reduce origin load and response latency by enabling API Gateway caching and positioning Amazon CloudFront in front of APIs and static assets as a content delivery network. Apply Amazon SNS subscription filter policies so each subscriber receives only the message subset it needs, reducing unnecessary processing across consumers.

API Gateway cachingAmazon CloudFrontSNS subscription filter policiesMessage filtering

Practice question for this objective

Free sampleTroubleshooting and Optimizationmedium

An order service publishes every order event to a single Amazon SNS topic. Three SQS queues subscribe to the topic, but an analytics queue should receive only events where the event message attribute orderStatus equals SHIPPED. Currently all three queues receive every event, and the team filters them inside the consumer, wasting consumer compute. The developer wants SNS to deliver only matching events to the analytics queue without changing the publisher. Which approach meets this requirement?

  • AAttach an SNS subscription filter policy to the analytics subscription that matches the orderStatus message attribute equal to SHIPPED. Correct
  • BCreate a second SNS topic dedicated to shipped events and reconfigure the order service to publish shipped events to it as well as the original topic.
  • CEnable raw message delivery on the analytics subscription so SNS strips the envelope and forwards only the shipped events to the analytics queue.
  • DSet a redrive policy on the analytics queue so events that do not match the shipped status are moved to a dead-letter queue instead of being processed.
Apply an SNS subscription filter policy to deliver only messages whose attributes match, reducing downstream consumer load. An SNS subscription filter policy is evaluated against each message's attributes before delivery, so SNS forwards a message to a subscription only when the attributes satisfy the policy, letting the analytics queue receive only SHIPPED events while the publisher and other subscriptions are unchanged.

Why A is correct: A subscription filter policy evaluates message attributes at the topic and delivers only matching messages to that subscription, so only shipped events reach the analytics queue without any publisher change.

Why B is wrong: A second topic works only if the publisher changes to route shipped events to it, which the requirement forbids, and it duplicates publishing logic the team is trying to avoid.

Why C is wrong: Raw message delivery changes the payload format passed to the queue but applies no condition, so the analytics queue still receives every event rather than only shipped ones.

Why D is wrong: A redrive policy routes messages to a dead-letter queue only after repeated processing failures, so it neither filters by attribute nor prevents non-matching events from arriving.

See more DVA-C02 practice questions, answers explained.

Exam traps in Troubleshooting and Optimization

Answers that look right on this material and are not. Each one is a distractor from a different question in the DVA-C02 bank for this domain.

  • Add a subscription filter policy that uses a numeric greater-than condition on the amount message attribute supplied by the publisher.

    Why it is wrong: The default filter scope evaluates message attributes, but the publisher sends amount in the body and cannot add attributes, so an attribute-scoped policy never matches.

  • Add a message attribute named riskScore on the publisher and filter on that attribute instead of the body.

    Why it is wrong: Attribute filtering is the usual default, but the stem states the publisher cannot be changed, so adding an attribute is not an available action here.

  • Raise the throttling burst and rate limits on the stage so API Gateway accepts more requests and forwards each one to the Lambda backend more quickly.

    Why it is wrong: Throttling limits cap request rates to protect the backend but still forward every accepted request to Lambda, so they reduce neither backend invocations nor latency for repeated reads.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.