This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Scenario 1: Protect against a malicious fabric administrator
Contoso's Hyper-V hosts meet the TPM prerequisites. The owner wants protection from fabric-administrator inspection of guest secrets. Which design fits?
Any attestation mode, provided every VM has a local vTPM.
TPM-trusted attestation and shielded policy, with separate HGS and owner authority.
Host-key attestation and encryption-supported policy, with owner keys on the Hyper-V hosts.
Scenario 2: A registered Hyper-V host runs an unapproved driver
An operator registered the Hyper-V host's public key yesterday. Today the Hyper-V host runs an unapproved driver. What can be concluded?
Registration automatically switched HGS away from TPM mode.
Key possession isn't measured-health evidence, and registration alone doesn't establish the active mode.
The registration proves the current driver state is approved.
Scenario 3: Version 2 is preferred but version 1 remains
HGS prefers version 2, yet matching legacy version 1 artifacts remain. Which change closes the unintended fallback path?
Rely on the HGS operating-system version to make fallback impossible.
Rename the legacy policies so they no longer mention version 1.
Inventory and deliberately retire unapproved version 1 artifacts after proving the version 2 path.
Scenario 4: One VM fails on a healthy Hyper-V host
Attestation passes and other protected VMs start. App01 fails during key release after an HGS key change. What should you investigate first?
App01
Replace App01's KP with one extracted from a new PDK.
Inspect App01's existing KP, its guardians, the KPS endpoint, and private-key availability on each HGS node.
Disable CI attestation checks.
Scenario 5: Servicing changes measured evidence
An approved firmware and driver update causes attestation rejection on one Hyper-V host. What's the appropriate response?
Verify the intended change, update approved evidence through change control, test, and retire obsolete artifacts afterward.
Temporarily allow all code and leave the broad policy in place for the rollout.
Capture that Hyper-V host's current evidence immediately and authorize it without review.
Scenario 6: The template was modified after signing
The PDK and VSC pass their preliminary applicability check, but the VHDX was changed afterward. Which outcome is required?
Change the PDK to accept all later images without investigating.
The VSC's existence is enough to trust any disk with the same filename.
Actual provisioning rejects the altered template despite preliminary applicability.
Scenario 7: Certificate renewal changes the key
An administrator proposes an HGS certificate using a legacy CSP and calls a new key pair a same-key renewal because the subject name is unchanged. What must change?
Use the required KSP-based HGS certificate profile and treat the new key pair as a rollover with dependent-artifact planning.
Use the HTTPS certificate for every signing and encryption purpose.
Nothing. Subject-name continuity preserves access to old KPs.
Scenario 8: New HGS primary keys are active
New primary keys are available on every HGS node. When can the old keys be retired?
After owners update affected existing KPs and the approved recovery plan covers retained backups, checkpoints, replicas, and PDKs.
After issuing a new PDK, regardless of deployed VMs or backups.
Immediately, because primary selection rewrites every existing KP.
Scenario 9: A deauthorized stolen Hyper-V host keeps running a shielded VM
The Hyper-V host was removed from primary HGS, but a shielded VM continues running on it. Recovery HGS wasn't changed. What's the correct response?
Wait for certificate expiry because it immediately erases every released secret.
Restore its registration because continued execution proves the withdrawal failed.
Contain the Hyper-V host, preserve evidence, withdraw applicable authorization at every HGS service, assess released/cached material, and recover on clean infrastructure.
Scenario 10: HGS is unreachable during a cold start
The primary HGS site is unavailable. What determines whether a protected VM can start?
Fallback should ignore attestation policy whenever the primary rejects the Hyper-V host.
A reachable authorized fallback path or an eligible offline cache for that Hyper-V host and shielded VM state is required. Otherwise the shielded VM's start remains blocked.
Any Hyper-V host that can read the VHDX can start it.
Scenario 11: Migration breaks after a Windows Server 2025 upgrade
The destination Hyper-V host passes attestation and is authorized by the VM. CredSSP migration fails after upgrade. Which action fits the evidence?
Investigate Credential Guard's effect on delegation and configure a supported Kerberos delegation design, while retaining independent destination checks.
Disable Credential Guard as the standard long-term fix.
Replace the destination Hyper-V host's TPM identity.
Scenario 12: Every HGS node is lost
The team has an HGS state export but used HSM-backed encryption keys. What's the recovery requirement?
Rebuild and initialize clean HGS, restore approved state, recover HSM/private-key access on every node, and reconstruct identity, DNS, cluster, and TLS dependencies.
Import the XML and assume all external keys, AD, and TLS are included.
Generate unrelated encryption keys with the old certificate subject names.
Scenario 13: Restore a backup from before key rollover
A consistent backup contains an old KP that authorizes a now-compromised guardian. What's the safe approach?
Keep only the VHDX and discard its associated protected state.
Re-enable that guardian in production solely to make the restore convenient.
Restore in isolation, inspect authorization, and use clean owner-authorized recovery/reprotection without silently restoring withdrawn trust.
Scenario 14: Recover a Windows guest's BitLocker material
An eligible shielded guest can't unlock its OS volume. Which recovery materials and authority are required by the documented owner recovery path?
Fabric administrator rights alone. A newly generated PDK is sufficient.
The matching original eligible PDK, owner guardian private keys, and a consistent disk in an isolated recovery environment, with protected handling of the decrypted .bek file.
.bek
Any HGS export, because it includes every owner's private keys.
You must answer all questions before checking your work.
Was this page helpful?
Need help with this topic?
Want to try using Ask Learn to clarify or guide you through this topic?