A jetty-plank inventory app receives https://VAULT_NAME.vault.azure.net/ and a managed identity. How should code address Key Vault secrets?
Select an answer to reveal the explanation.
Short Explanation
Vault URI plus credential into SecretClient—that is the address book entry. The managed identity is the badge; stuffing every secret into appsettings.json recreates the problem Key Vault solved.
Full Explanation
Addressing Key Vault from code means building a SecretClient with the vault base URI (https://VAULT_NAME.vault.azure.net/) and a TokenCredential such as the jetty-plank inventory app's managed identity. Individual secrets are then fetched by name and optional version. Pasting every secret into appsettings.json defeats the purpose of the vault URI and identity you were given.
Downloading all secrets once into appsettings.json and disabling the vault thereafter freezes a local copy, blocks rotation, and reintroduces plaintext configuration drift. Hard-coding each secret in source while leaving the vault URI as a comment provides no runtime security and fails code review for municipal systems. Calling Event Hubs Send with the vault URI because messaging replaces SecretClient confuses an event ingest API with the secrets data plane—Event Hubs will not resolve Key Vault secrets for you.
Exam caveat: the vault URI identifies the vault resource; RBAC or access policies on that vault still decide whether the managed identity may GetSecret. Operational check: construct SecretClient from URI plus DefaultAzureCredential or managed identity, fetch one inventory secret, deny the identity temporarily, and confirm the next GetSecret returns 403 rather than silently reading an appsettings fallback.