Your multi-agent solution stores third-party API keys in Azure Key Vault. Agents currently fail for up to an hour after secrets rotate because they cache values at process start. Operations needs rotation without multi-hour outages and without putting secrets in source control. What should you implement?
Select an answer to reveal the explanation.
Short Explanation
Correct answer: D. Treat secrets like milk in the fridge, not wine in the cellar—fetch fresh, don’t bottle them into the image at build time. Runtime Key Vault resolution with short TTL or on-failure refresh lets rotation land without an hour of dead agents, and nothing sensitive lands in Git.
Full Explanation
Production multi-agent solutions should retrieve secrets from Azure Key Vault with least-privilege identity access and support rotation. Option D is correct: runtime resolution (or middleware with short TTL), versioned secret references, and refresh-on-failure/lease patterns keep agents aligned with rotated keys without redeploying from source.
Option A is incorrect because committing secrets—even “encrypted” appsettings—into Git expands exposure and couples rotation to full redeploys.
Option B is incorrect: soft-delete and purge protection are data-protection features for accidental deletion; disabling them does not fix client-side caching and weakens recovery posture.
Option C is incorrect: deploy-time-only environment variables recreate the stale-cache problem after rotation until the next redeploy, and static parameter files risk secret sprawl.
Exam tip: Key Vault + managed identity + runtime fetch/rotation awareness is the expected pattern; anything that bakes secrets into images, repos, or long-lived process env is a distractor.