easymultiple choiceObjective-mapped

An order-processing system publishes an event whenever a payment succeeds. Three downstream services (inventory, shipping, and analytics) must react independently. Analytics sometimes has high latency, but order processing must not be blocked. What is the best AWS approach to decouple these consumers?

Question 1easymultiple choice
Full question →

An order-processing system publishes an event whenever a payment succeeds. Three downstream services (inventory, shipping, and analytics) must react independently. Analytics sometimes has high latency, but order processing must not be blocked. What is the best AWS approach to decouple these consumers?

Answer choices

Why each option matters

Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.

A

Distractor review

Have order processing call each service synchronously via HTTPS and retry on failures.

Synchronous calls couple the producer to each consumer’s availability and latency. If analytics is slow or temporarily unavailable, order processing can be delayed or fail, violating the requirement.

B

Best answer

Publish payment events to SNS (or EventBridge) and let each downstream service consume independently (for example, via SQS queues or other async targets).

Using pub/sub decouples the producer from consumers. Order processing publishes once and can complete without waiting for each downstream service. Each consumer receives events independently, so analytics latency does not directly block inventory or shipping processing.

C

Distractor review

Store events in a single relational database table and let consumers poll continuously for new rows.

Polling a database couples scaling and failure handling to the DB layer and increases load. It also makes backpressure and failure isolation harder compared with managed messaging.

D

Distractor review

Send events directly from the producer to each consumer EC2 instance using SSH tunnels.

SSH-based delivery is not a resilient messaging pattern. It adds operational fragility (instance availability, networking, authentication/authorization, retries) and lacks the decoupling and durable delivery semantics expected for event distribution.

Common exam trap

Common exam trap: answer the scenario, not the keyword

Many certification questions include familiar terms but test a specific constraint. Read the exact wording before choosing an answer that is generally true but wrong for this case.

Technical deep dive

How to think about this question

This question should be treated as a scenario, not a definition check. Identify the problem, the constraint and the best action. Then compare each option against those facts.

KKey Concepts to Remember

  • Read the scenario before looking for a memorised answer.
  • Find the constraint that changes the correct option.
  • Eliminate answers that are true in general but not in this case.
  • Use explanations to understand the rule behind the answer.

TExam Day Tips

  • Underline the problem statement mentally.
  • Watch for words such as best, first, most likely and least administrative effort.
  • Review why wrong options are wrong, not only why the correct option is correct.

Related practice questions

Related SAA-C03 practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

More questions from this exam

Keep practising from the same exam bank, or move into a focused topic page if this question exposed a weak area.

FAQ

Questions learners often ask

What does this SAA-C03 question test?

Read the scenario before looking for a memorised answer.

What is the correct answer to this question?

The correct answer is: Publish payment events to SNS (or EventBridge) and let each downstream service consume independently (for example, via SQS queues or other async targets). — To ensure slow consumers do not block order processing, use an asynchronous decoupling mechanism such as SNS or Amazon EventBridge. The order-processing system publishes a payment-success event once. Each downstream service consumes the event independently (commonly by subscribing via SQS, Lambda, or other async targets). This design provides failure and latency isolation: if analytics is slow or experiences transient issues, inventory and shipping can continue processing based on their own event consumption and scaling behavior. A is wrong because synchronous HTTPS ties order-processing responsiveness to the slowest consumer. C is wrong because database polling is a coupled approach that can create scaling and failure isolation problems at the database layer. D is wrong because SSH tunnel delivery is brittle and does not provide the managed pub/sub decoupling needed for resilience.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.

Discussion

Loading comments…

Sign in to join the discussion.