A zinc-roof workshop wants one configuration client in the app, but DbPassword must remain a vault secret. What App Configuration pattern meets that goal?
Select an answer to reveal the explanation.
Short Explanation
One config client, two stores: put a Key Vault reference in App Configuration for DbPassword. The app still needs vault get-secret rights through its identity—the reference is a pointer, not a plaintext copy.
Full Explanation
Azure App Configuration supports Key Vault references: the zinc-roof workshop stores a pointer for DbPassword in App Configuration while the secret value remains in Key Vault. A single configuration client can load ordinary settings and resolve referenced secrets, provided the app's identity has get permission on the vault. That pattern meets one-client-with-password-still-vaulted without duplicating plaintext into the config store.
Copying DbPassword into an App Configuration key-value so the vault can be deleted fails because App Configuration is not a secret store; plaintext there widens exposure and removes rotation and soft-delete benefits of Key Vault. Embedding DbPassword in the container image ENV ignores both managed stores, bakes credentials into layers/history, and forces image rebuilds for rotation. Replacing DbPassword with an Event Grid topic name fails functionally—a topic name is not a database credential—and confuses messaging topology with secret management.
Exam caveat: resolving a Key Vault reference still performs a vault data-plane call; network rules, firewalls, and RBAC must allow the app identity at runtime, not only at deploy time. Operational check: create the reference in App Configuration, grant the workshop app's managed identity Secrets User (or equivalent access policy), restart or refresh once, confirm the connection string builds correctly, then rotate the vault secret and ensure the next refresh picks up the new version without editing App Configuration plaintext.