A utilities dashboard runs its Cisco-API worker “in the cloud” with one token file, one region, and no degraded path when that hop fails. What does that design still lack?
Select an answer to reveal the explanation.
Short Explanation
Putting one lockbox in a skyscraper does not make it two lockboxes. Cloud placement alone is not resiliency. Redundant paths and a degraded mode when a hop fails are the real properties.
Full Explanation
Placing a utilities dashboard's Cisco-API worker in the cloud with one token file, one region, and no degraded path does not by itself create resiliency. Cloud is a hosting location. Actual HA needs redundant paths, multi-AZ or multi-region thinking where appropriate, secret redundancy or rotation strategy, health-aware traffic management, and graceful degradation when the hop fails. Without those properties, a cloudy single point of failure is still a single point of failure.
Swapping IaaS logos on a slide fails because branding is not an availability control. Listing more instance families in the same single region fails if traffic and secrets still depend on one path and one failure domain. Moving the same single token file onto a larger VM fails by confusing vertical size with redundancy and degradation design.
Exam caveat: migrating to cloud is a common distractor; the exam scores resiliency mechanisms, not placement marketing.
Operational check: induce hop failure (bad token, blocked egress, region dependency) and verify the dashboard shows a controlled degraded state rather than a hard-down blank utility view with no alternate path.
Ask whether a second path exists when the primary region, token store, or egress path dies, and whether the utilities UI can show degraded Cisco data instead of failing closed. Cloud placement can host those controls; it does not replace them. Resiliency is properties you can test, not a checkbox that the worker hostname ends in a public cloud DNS name.