A water utility separates DMVPN hubs onto dual mGRE clouds so public-safety sites keep an independent path if one overlay fails. What resiliency pattern does that describe?
Select an answer to reveal the explanation.
Short Explanation
Dual-cloud dual-hub is two separate emergency radio channels — if one channel dies, public-safety still has the other. More spoke config, better isolation. That is the resiliency pattern water utilities pick when correlated overlay failure is unacceptable.
Full Explanation
Dual-hub dual-cloud DMVPN places hubs in separate mGRE overlay clouds so a water utility’s public-safety sites keep an independent path if one overlay fails. Spokes typically maintain tunnels toward each hub cloud, trading configuration complexity for stronger failure-domain isolation than single-cloud dual hub.
Single-cloud dual hub maximizes correlated failure between hubs relative to dual cloud—it is the contrasting pattern. Phase 1 hub-only forwarding with redirect disabled on both clouds is not the dual-cloud resiliency definition. Extranet RT leaking between hubs imports MPLS VPN concepts that do not define DMVPN dual-cloud design.
Exam caveat: dual-cloud = separate overlay failure domains; dual-hub alone does not equal dual-cloud.
Operational check: build two clouds, point public-safety spokes at both, fail one cloud’s hub path, confirm the alternate cloud carries traffic, and measure spoke configuration complexity against the resiliency gain. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services. Re-validate after the next platform or policy change.