CLF-C02 Cloud Concepts 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 all services call each other directly via synchronous API calls

  Why it's wrong here

  Direct synchronous API calls tether each service's availability and performance to the services it calls. If a downstream service is slow, the upstream service's threads block waiting for a response, and under load, timeout and retry storms can cascade failures across the whole system. Every added call also increases the critical path latency, because the caller cannot return work until the entire chain completes, and this makes capacity planning difficult since every service must be provisioned to handle peak instantaneous load together.

• ✓

  Use Amazon SQS or Amazon SNS between services to decouple them

  Why this is correct

  Amazon SQS and Amazon SNS break the direct temporal dependency between services. With SQS, a producer sends a message to a queue and immediately returns, while consumers poll and process messages at their own pace, so bursts of traffic are buffered and backpressure is absorbed. With SNS, events are published to a topic and fanned out to multiple subscribers, so new subscribers can be added without the producer knowing about them. This loose coupling lets each service scale, deploy, and fail independently without blocking or requiring the others to be online in real time.

• ✗

  Deploy all application components on a single large EC2 instance

  Why it's wrong here

  Running every component in a single large EC2 instance combines infrastructure, process, and lifecycle risks. The entire application shares the same operating system, memory, CPU, and disk, so a memory leak or crash in one component affects all other components, and scaling is limited to vertically resizing the instance. If that instance fails, the whole application fails, creating a single point of failure that also prevents independent rollouts and isolated performance tuning for individual services.

• ✗

  Use a single shared database for all microservices

  Why it's wrong here

  A single shared database couples services at the persistence layer, making them interdependent in ways that are hard to refactor. Schema changes for one service can break other services that query the same tables, and indexes, locks, and connection pools become shared resources that cause contention and latency spikes. This also forces all services to use the same storage semantics and transaction patterns, preventing teams from independently choosing the right data model, migrating schemas, or scaling read and write workloads, which defeats the purpose of microservices.

Go deeper

Related to this question