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.

• ✗

  Design for failure by adding redundant instances

  Why it's wrong here

  Adding redundant instances—for example, deploying multiple EC2 instances behind an Application Load Balancer—improves raw availability but does not break the synchronous dependency between components. If component A directly calls component B and B fails, every redundant copy of A will generate more failed requests and retries, potentially overwhelming B or exhausting connection pools. Redundancy is a useful fault-tolerance tactic, but it does not isolate failures or decouple the components' lifecycles, so the architectural coupling issue remains unresolved.

• ✓

  Implement loose coupling through asynchronous messaging between components

  Why this is correct

  Loose coupling via asynchronous messaging—such as Amazon SQS queues, SNS topics, or EventBridge event buses—allows components to interact without requiring both to be online at the same moment. A producer sends a message to a durable queue, and the consumer processes it later, with the message persisting through transient failures and enabling automatic retries. This design isolates failures because a consumer outage does not block the producer, and each component can be scaled, deployed, and updated independently. It is the core pattern for building resilient, fault-isolated microservices on AWS.

• ✗

  Use larger instance types to handle all components on fewer servers

  Why it's wrong here

  Consolidating multiple components onto a smaller number of larger instance types intensifies coupling by placing them in a single failure domain. If that one instance fails, all the components running on it go down at once, and the system loses more functionality in a single event compared to a distributed deployment. Vertical scaling also hits hard instance-size limits and does not introduce any interface or message boundary between components, so the underlying synchronous, tightly coupled interaction remains unchanged. This approach is the opposite of the isolation required to prevent cascading failures.

• ✗

  Enable AWS Auto Scaling to handle traffic variability

  Why it's wrong here

  AWS Auto Scaling adjusts the number of instances in response to demand, which helps handle traffic variability but does not alter how components communicate. In a tightly coupled application—for example, one that relies on synchronous HTTP calls with no circuit breaker or timeout—Auto Scaling cannot prevent a dependency failure from propagating to every connected client. Scaling out adds capacity or replicas, but the coupling problem persists even at larger scales, and might even be masked until a real dependency outage occurs. Auto Scaling is meant to complement, not replace, an intentionally decoupled architecture.

Go deeper

Related to this question