Restrict Pod Access to Azure Key Vault Secrets in AKS
You are designing a microservices application running on Azure Kubernetes Service (AKS). You need to ensure that secrets (e.g., API keys, connection strings) are securely stored and automatically rotated without application downtime. What is the recommended approach?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use Azure Key Vault with the Secrets Store CSI driver to mount secrets as volumes and enable rotation.
The Azure Key Vault provider for the Secrets Store CSI driver mounts secrets from Azure Key Vault as volumes in AKS pods and supports auto-rotation via the secret rotation feature, which periodically re-fetches updated secrets and updates the mounted files without restarting the application. This satisfies the requirement for secure storage in Key Vault plus automatic rotation with no downtime. Option A is aimed at application configuration scenarios and does not natively mount or rotate secrets into AKS pods. Option B stores secrets in Kubernetes Secrets, which are only base64-encoded and lack the managed rotation and centralized security of Key Vault. Option D injects secrets as environment variables, which cannot be updated in a running container without a pod restart, causing downtime.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store secrets in Azure App Configuration with key vault references.
Why it's wrong here
App Configuration with Key Vault references centralises configuration and resolves secrets at read time, but it does not push rotated values into running pods, so rotation needs an application restart or sidecar. It suits feature-flag and config management, not zero-downtime secret rotation in AKS.
- ✗
Store secrets as Kubernetes Secrets and use a controller to rotate them.
Why it's wrong here
Native Kubernetes Secrets are base64-encoded, not encrypted at rest by default, and rotation requires pods to remount or restart, causing downtime. A rotation controller helps, but the underlying store lacks Key Vault's HSM-backed protection. Kubernetes Secrets suit non-sensitive config, not regulated credentials.
- ✓
Use Azure Key Vault with the Secrets Store CSI driver to mount secrets as volumes and enable rotation.
Why this is correct
The Secrets Store CSI driver mounts Azure Key Vault secrets as volumes in AKS pods, so applications read them from the filesystem. Enabling rotation updates the mounted content automatically, delivering secure storage and rotation without application downtime.
- ✗
Inject secrets as environment variables from Azure Key Vault using a pod identity.
Why it's wrong here
Environment variables are captured at pod start, so rotated secrets are not picked up until the pod restarts, breaking the no-downtime requirement. Pod identity injection is tempting because it removes credentials from manifests, but it suits static startup configuration rather than live rotation.
Go deeper
Related to this question
About these practice questions
One of 605 original SC-100 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SC-100 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SC-100 exam.