Stamp Update Failure During a Maintenance Window
A connected Azure Stack Hub stamp is scheduled for an update during a weekend maintenance window. The operator has verified the update package and started the update. Six hours in, the update fails on an infrastructure role. The stamp's admin portal is reachable, but several tenant VMs are unresponsive. The operator sees alerts for a failed infrastructure role and for storage latency. The operator has a support case open and is waiting for a response. The business has a Monday morning deadline for a critical tenant application running on the stamp. The operator wants to retry the update immediately to recover before Monday.
1. Should the operator retry the update immediately? Justify the recommendation.
Read the worked answer
No. Retrying an update that failed on an infrastructure role without understanding the failure risks making the stamp worse. The correct sequence is to stabilize, diagnose, and then decide.
Reasoning:
- A failed infrastructure role means part of the stamp's control plane is unhealthy. Retrying the update can compound the failure and may leave the stamp in a state that requires Microsoft-assisted recovery.
- Tenant VMs are unresponsive and storage latency alerts are active. Both symptoms point to an infrastructure-level problem, not a tenant configuration issue. Restarting the update while storage is degraded can cause data loss or corruption.
- The support case is open. The operator should provide logs, the failing role, and the alert timeline, and follow Microsoft guidance before any retry.
- The Monday deadline is a business constraint, not a technical justification for risky action. The operator should communicate the risk and set expectations.
The judgment: the exam tests whether you prioritize stamp integrity over schedule pressure. Recovery from a failed update is a controlled process, not a retry loop.
2. What immediate actions should the operator take to protect the stamp and the critical tenant application?
Read the worked answer
Immediate actions:
- Stop the update and do not retry until Microsoft support advises.
- Capture and preserve logs from the failed role and the update run, and attach them to the support case.
- Check the health of infrastructure roles in the admin portal and record which roles are degraded.
- Verify storage health and avoid operations that write heavily to the degraded storage until latency normalizes.
- For the critical tenant application, identify whether it can be failed over to an external environment or restored from backup outside the stamp. If not, document the dependency and escalate to the business owner.
- Communicate status to stakeholders with a realistic timeline based on support guidance, not on the original window.
The judgment: protect the stamp first, preserve evidence, and only then plan recovery. The critical application's fate depends on whether an external fallback exists, which should have been designed before the update.