easyMultiple ChoiceObjective-mapped
SC-100 Practice Question: Designing an application architecture using Azure…
A company is designing an application architecture using Azure Kubernetes Service (AKS) and Azure Cosmos DB. The application requires that secrets (database connection strings) be injected into pods securely without storing them in the container image. The solution must minimize management overhead. What is the recommended approach?
⚠ Common exam trap
Test-takers frequently assume Kubernetes Secrets are inherently secure because they are base64-encoded, but the exam tests the understanding that Secrets are only obfuscated, not encrypted by default, and that a managed external secrets store like Azure Key Vault is the recommended pattern for production-grade secret management with minimal overhead.
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 Provider for Secrets Store CSI Driver to mount secrets as volumes in pods.
The Azure Key Vault Provider for Secrets Store CSI Driver integrates directly with AKS to securely inject secrets from Azure Key Vault into pods as mounted volumes or environment variables, without storing them in container images or Kubernetes objects. This approach minimizes management overhead by leveraging Azure-managed Key Vault for secret lifecycle management and avoids the operational burden of manually managing Kubernetes Secrets.
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 a Kubernetes ConfigMap and reference them in the deployment YAML.
Why it's wrong here
Kubernetes ConfigMaps are designed for non-sensitive configuration data such as plaintext values, and they store data in etcd without any form of encryption. Storing secrets in a ConfigMap exposes them to anyone with read access to the API server or etcd, and the deployment YAML reference simply places the plaintext value into the pod environment, leaving no audit trail or rotation capability. This approach violates the principle of least privilege and fails to meet enterprise security requirements for secret management.
- ✓
Use Azure Key Vault Provider for Secrets Store CSI Driver to mount secrets as volumes in pods.
Why this is correct
The Azure Key Vault Provider for Secrets Store CSI Driver securely injects secrets from Azure Key Vault into pods as mounted volumes or environment variables, using a managed identity for authentication to avoid hardcoding any credentials. Secrets are never stored in Kubernetes etcd, and the provider integrates with Azure Key Vault's built-in rotation, access policies, and audit logging, ensuring that secret access is controlled and traceable. This native Azure integration provides a fully managed, secure, and scalable solution for secret management in AKS, satisfying both operational and compliance needs.
- ✗
Define secrets in a Kubernetes Secret object and reference them in the pod spec.
Why it's wrong here
Kubernetes Secrets are merely base64-encoded, which is not encryption, and by default they are stored in etcd in cleartext unless a KMS encryption provider is configured. Even with encryption at rest, Secrets are accessible to any principal with read access to the API server, and namespace-wide RBAC permissions often give pods more visibility than required, while rotation remains a manual and error-prone process without a centralized audit trail. This approach shifts the burden of security management onto the cluster administrator and does not provide the robust secret lifecycle controls of a dedicated vault.
- ✗
Hardcode the connection string in an environment variable in the deployment manifest.
Why it's wrong here
Hardcoding a connection string directly in a deployment manifest means the secret appears in plaintext within the YAML file, which is typically stored in a source control repository and displayed in logs, making it immediately visible to anyone with access to those artifacts. This practice offers no encryption, no access control, no audit logging, and no mechanism for rotation, so any compromise of the manifest or cluster directly exposes the application's credentials. It violates fundamental security best practices and would fail any compliance or security review, leaving the application critically vulnerable to credential theft.
Go deeper
Related to this question
About these practice questions
This SC-100 question is part of Courseiva's 208-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.