Azure Dev Boxes and Azure Key Vault: Private Connectivity for Managed Identity Secret Access After Restart

Repeatable developer workstation provisioning is being designed around Azure Dev Boxes placed in a custom virtual network with a private endpoint to Azure Key Vault. The goal is secret retrieval via system-assigned managed identity without public internet egress.

The integration boundary involves Dev Box VM lifecycle events such as auto-shutdown and auto-start, and the persistence of private endpoint reachability and private DNS resolution for privatelink.vaultcore.azure.net across VM deallocation and reallocation. Managed identity authorization is scoped to the Dev Box resource, not the interactive user session, and custom VNet support is region and SKU dependent.

Documentation does not clearly guarantee automatic re-establishment of private connectivity after restart or project changes, and firewall rules that block public access may affect provisioning.

Does a system-assigned managed identity retain Key Vault access over the private endpoint after an auto-shutdown/start cycle without manual intervention? Is private DNS resolution for the vault guaranteed to persist across VM deallocation and reallocation? How does Key Vault firewall configuration interact with initial Dev Box provisioning when public access is denied?