After a single rack failure killed on-premises apps, staff want cloud high availability. At describe depth, what does that benefit emphasize?
Select an answer to reveal the explanation.
Short Explanation
One dead rack took the whole carnival down. High availability is spreading the rides so one broken generator does not darken every booth. Cloud makes that spread-across-failures story part of the architecture conversation—not a portal lab.
Full Explanation
After a single rack failure killed on-premises apps, high availability at describe depth emphasizes designing so workloads can span failures—remaining available when a single rack or component fails. Cloud platforms support spreading across fault domains and regions conceptually without turning the question into an AZ-104 configuration lab. The story is survive a localized failure, not memorize every portal blade.
Placing every workload on one physical rack so failures are easier to notice concentrates risk, the opposite of HA. Turning off redundancy because HA supposedly means accepting longer outages inverts the benefit. Limiting HA to printers and excluding line-of-business apps invents a scope limit that does not exist.
Exam caveat: AZ-900 wants the benefit story (survive component failure), not step-by-step availability-set or zone wiring; if an item starts demanding portal click-paths, you have left fundamentals describe depth. Keep answers at the benefit layer unless the exam clearly asks how.
Operational check: inventory which city apps still live on a single host or single rack equivalent in cloud (one instance, one zone only), and flag them for multi-instance or multi-zone HA design discussions—without requiring the fundamentals audience to implement the controls themselves.