Canal-authority secrets in Key Vault must not be reachable from the public Internet. Which configuration best meets that requirement?
Select an answer to reveal the explanation.
Short Explanation
Shut the public door on the vault and walk secrets in through a private endpoint. Point DNS at privatelink.vaultcore.azure.net so callers stay on the private path instead of the open Internet.
Full Explanation
Canal-authority secrets that must not be reachable from the public Internet require shutting public data-plane exposure and providing a private path. Disabling public network access (or setting the Key Vault firewall default action to Deny) and connecting a private endpoint with DNS for privatelink.vaultcore.azure.net keeps callers on private connectivity. That combination is the standard private-access pattern for Key Vault when Internet reachability is out of policy.
Leaving public network access enabled and relying only on a long shared access signature on each secret fails by concept: Key Vault data-plane authorization is Entra ID or access policies/RBAC, not SAS tokens as used on Storage, and a public endpoint still exposes the attack surface. Opening the vault to All networks and assigning Key Vault Contributor to every canal operator fails because All networks keeps the public path and Contributor is a broad control-plane role, not least-privilege secret read. Storing secrets in a storage account public container fails confidentiality and abandons Key Vault’s access, logging, and key-management controls.
Exam caveat: private endpoint alone is incomplete without DNS that resolves the vault hostname to the privatelink zone; mis-DNS sends clients back to public endpoints. Operational check: disable public access or Deny default, deploy the private endpoint, validate privatelink.vaultcore.azure.net resolution from the app subnet, confirm secret Get succeeds privately, and confirm a host on the public Internet cannot reach the data plane.