A city compares two AWS designs: one cheaper but fragile, and one more resilient but more expensive. What does that comparison illustrate about Well-Architected pillars?
Select an answer to reveal the explanation.
Short Explanation
Cheap-but-fragile versus sturdy-but-costlier is a classic tug-of-war between two different scorecards. Cost Optimization and Reliability are separate pillars, so teams weigh trade-offs instead of pretending they are one idea. Reliability is real, and it does not ban spending when resilience is required.
Full Explanation
Comparing a cheaper-but-fragile AWS design with a more resilient-but-more-expensive one illustrates that Cost Optimization and Reliability are distinct Well-Architected pillars that can trade off against each other. Municipal architects must make explicit risk-versus-spend decisions rather than pretending one pillar absorbs the other.
Saying the two pillars are the same under two marketing names is false. Claiming only Cost Optimization exists denies Reliability’s pillar status. Preferring fragile designs because Reliability forbids spending money misstates both pillars and would be reckless for citizen services.
Exam caveat: CLF-C02 expects awareness of pillar trade-offs, especially cost versus reliability. Operational check: for a critical civic workload, document the availability target, estimate the cost of the resilient design versus the fragile one, and record the accepted trade-off with an accountable owner.
Municipal teams should keep a one-page decision record linking this Cloud Practitioner concept to resident outcomes, revisit it after major traffic or compliance changes, and ensure runbooks still match the chosen design.
Municipal teams should keep a one-page decision record linking this Cloud Practitioner concept to resident outcomes, revisit it after major traffic or compliance changes, and ensure runbooks still match the chosen design.