SAA-C03 Design Resilient Architectures 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.

• ✗

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

  Why it's wrong here

  Synchronous HTTPS calls force the order processing service to wait for every downstream service to respond before continuing, directly coupling its success to the availability and latency of each consumer. A slow or failed analytics service would not only delay inventory and shipping but also require retries that can cause duplicate side effects or timeouts, violating the requirement that payment processing proceed independently. This approach lacks the durable, asynchronous message delivery that managed pub/sub services provide, so any service downtime can block the entire order flow.

• ✓

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

  Why this is correct

  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.

• ✗

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

  Why it's wrong here

  Storing events in a shared relational database and having consumers poll for new rows turns the database into a central bottleneck and a single point of failure, while adding latency proportional to the polling interval. Every consumer must repeatedly query the same table, increasing read load and making it difficult to scale independently because lock contention and index overhead can degrade order processing itself. Unlike a managed messaging service, this pattern does not offer built-in fan-out, per-consumer offsets, or dead-letter queues, so failure isolation and replay become manual and error-prone.

• ✗

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

  Why it's wrong here

  Using SSH tunnels to push events directly to each consumer EC2 instance requires the producer to maintain live network connections and handle authentication for every instance, making retries, backpressure, and instance replacement extremely fragile. Since SSH is a point-to-point transport with no built-in persistence or delivery acknowledgment, any network hiccup or instance reboot would cause events to be lost without a durable record. This pattern also tightly couples the producer to the specific IP addresses and lifecycle of consumers, offering none of the decoupling or reliability expected from a managed event distribution service.

Go deeper

Related to this question