AZ-204 Implement Azure security Practice Question
A company is building a microservices application on Azure Container Instances. Each microservice needs to authenticate to Azure Key Vault to retrieve secrets. They want to avoid storing any credentials in the container images or environment variables. What should they do?
⚠ Common exam trap
Many candidates confuse Docker secrets (which still require credential injection at runtime) with Azure managed identities (which eliminate the need for any stored credentials), or they may incorrectly think SAS tokens can be used for Key Vault authentication, when SAS tokens are strictly for Azure Storage.
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
✓
Enable managed identity for the container group and grant it access to Key Vault.
Azure Container Instances supports managed identities, allowing the container group to authenticate to Azure Key Vault without any credentials stored in the image or environment variables. By enabling a system-assigned or user-assigned managed identity on the container group and granting that identity the appropriate Key Vault access policy (e.g., 'Get' secret permission), the application can acquire an Azure AD token from the Instance Metadata Service (IMDS) endpoint and use it to retrieve secrets securely.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use Docker secrets mounted as volumes.
Why it's wrong here
Docker secrets are a feature specifically designed for Docker Swarm and Kubernetes environments to securely store and manage sensitive data, making them available to containers as mounted files. However, Azure Container Instances (ACI) is a serverless container service that operates independently of these orchestrators and does not natively support or integrate with Docker Swarm or Kubernetes-specific secret management mechanisms. Therefore, attempting to use Docker secrets directly within an ACI container group for accessing Azure Key Vault would be incompatible and fail, as ACI provides its own distinct methods for secure credential handling.
- ✓
Enable managed identity for the container group and grant it access to Key Vault.
Why this is correct
Enabling a managed identity for the Azure Container Instances (ACI) container group provisions an automatically managed identity within Azure Active Directory (Azure AD). This identity can then be granted specific role-based access control (RBAC) permissions to an Azure Key Vault, allowing the containerized application to securely retrieve secrets, keys, or certificates. This method eliminates the need for hardcoded credentials, connection strings, or client secrets within the application code or environment variables, significantly enhancing security by preventing credential exposure and simplifying credential rotation.
- ✗
Use a shared access signature (SAS) token to access Key Vault.
Why it's wrong here
Shared Access Signature (SAS) tokens are a security mechanism primarily used to grant time-limited, delegated access to specific resources within Azure Storage accounts, such as blobs, queues, tables, or files. They provide granular control over permissions and validity periods for storage operations. However, Azure Key Vault utilizes Azure Active Directory (Azure AD) for authentication and authorization, relying on service principals, managed identities, or user accounts with appropriate RBAC roles. SAS tokens are fundamentally incompatible with Key Vault's security model and cannot be used to access its secrets or keys.
- ✗
Store the Key Vault URI and a client secret in environment variables.
Why it's wrong here
Storing sensitive information like a Key Vault client secret directly in environment variables represents a significant security vulnerability. While environment variables offer a convenient way to configure applications, they are often easily accessible and viewable by anyone with sufficient access to the container host or management plane, potentially exposing the client secret to unauthorized users or systems. A client secret is a long-lived credential that, if compromised, could grant persistent and unauthorized access to the Key Vault, making this approach highly insecure and against best practices for secret management in production environments.
Go deeper
Related to this question
Learn chapter
Azure Functions Development
Key term
Azure Container Instances
Azure Container Instances (ACI) is a PaaS service that lets you run a container directly in Azure without managing any underlying servers or orchestration.
Key term
Key Vault Secrets
Key Vault Secrets are secure containers in Microsoft Azure that store sensitive information like passwords, connection strings, and API keys, keeping them encrypted and accessible only to authorized applications and users.
About these practice questions
This AZ-204 question is part of Courseiva's 881-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 AZ-204 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 AZ-204 exam.