An application has a stateless web tier that any server can serve and a stateful database that must keep one consistent copy of its data and move to a standby node if the primary node fails. Which pairing of resilience techniques best fits the two tiers?
Select an answer to reveal the explanation.
Short Explanation
Stateless servers are interchangeable, so you just spread the traffic with a load balancer. A database that has to keep one true copy needs nodes that coordinate and take over for each other, and that's a cluster. Flip those and you're fighting the way each tier actually works.
Full Explanation
Load balancing distributes requests across a pool of equivalent servers and removes unhealthy ones from rotation. It suits a stateless web tier because no request depends on which server handled the previous one, so any healthy node can serve any client. Clustering joins nodes that share or synchronize state and coordinate failover, which suits a database that must present one consistent copy of its data and promote a standby when the primary fails. Reversing the pairing places coordination overhead where it adds little value and leaves the database behind a load balancer that would send writes to independent copies, risking divergent data. Load balancing both tiers with no shared state between database nodes produces exactly that split-brain outcome, because each node would accept changes the others never see. Clustering the web tier while autoscaling the database is also mismatched: autoscaling adds instances for demand, but a stateful database cannot simply clone new nodes and stay consistent without replication and cluster coordination behind it. Exam caveat: real designs often combine techniques, but the question asks which fits each tier's nature. Operational check: remove one web server from rotation and confirm sessions continue on the others, then fail the primary database node and confirm the cluster promotes the standby with no data loss.