City council asks whether high availability means the citizen portal will never experience any outage forever. How should IT frame high availability at Cloud Practitioner depth?
Select an answer to reveal the explanation.
Short Explanation
High availability is not a magic spell of infinite uptime. It means you design so the portal can keep serving when a piece breaks—not that nothing will ever hiccup. Council hears resilience-through-failure, not an impossible forever-zero promise.
Full Explanation
At Cloud Practitioner depth, high availability means designing systems to remain accessible through component failures—not a promise of absolute zero downtime forever. City council should hear that the citizen portal is architected to survive disk, host, or AZ-level failures within the design's scope, while still understanding that complex distributed systems can experience degraded periods and that "never any outage forever" is not a realistic absolute.
Framing high availability as a contract that AWS will never have any service interruption worldwide overstates platform guarantees and ignores shared responsibility for architecture. Saying high availability only means buying the cheapest CPU family in one Region confuses pricing with resilience design. Equating high availability with economies of scale collapses two distinct concepts—one about failure continuity, one about unit cost.
Exam caveat: CLF-C02 expects precise vocabulary: HA is design-for-failure accessibility, not an SLA tattoo of infinite perfection, not CPU bargain hunting, and not economies of scale. Operational check: present council with the portal's multi-AZ (or equivalent) design, the failure modes it covers, and the residual risks it does not eliminate; then schedule a failure-injection or AZ-impairment drill and report residual error rates honestly.