A fen-boardwalk ticket API needs StripeLikeKey from Key Vault at startup. Which SDK approach should the developer use?
Select an answer to reveal the explanation.
Short Explanation
Startup needs a secret string? SecretClient.GetSecret with a proper credential. Do not ship a .env of production keys on the worker disk, and do not pretend Insights is your vault.
Full Explanation
String application secrets such as an API key are Key Vault secrets. At startup the fen-boardwalk ticket API should construct a SecretClient with the vault URI and a credential (managed identity in Azure, developer credentials locally), then call GetSecret for StripeLikeKey. That keeps the value off the worker disk and out of the deployment package while still making it available to configuration binding.
Checking a plaintext .env into the deployment package and never calling Key Vault recreates secret sprawl on every host image and backup. Calling KeyClient.Encrypt on a made-up key name to retrieve string secrets fails the object model: KeyClient performs cryptographic operations with keys; it does not return arbitrary secret strings the way SecretClient.GetSecret does. Reading the secret from Application Insights transaction search at boot fails because Insights stores telemetry, not authoritative secret material, and searching traces for secrets is both unreliable and a leakage smell.
Exam caveat: distinguish SecretClient, KeyClient, and CertificateClient early—AZ-204 loves mixing those verbs. Operational check: boot the ticket API with only vault URI plus identity and no .env key, confirm GetSecret succeeds, revoke the identity's secrets-get role briefly in a test vault, and verify startup fails closed rather than falling back to a packaged plaintext file.