AZ-104 Deploy and Manage Azure Compute Practice Question
Exhibit
Template excerpt:
```
resources:
- type: Microsoft.ContainerInstance/containerGroups
name: cg-transform
properties:
containers:
- name: transform
properties:
image: contoso.azurecr.io/transform:3.0
imageRegistryCredentials: []
```
Requirement: the image is stored in Azure Container Registry and no username, password, or connection string may be embedded in the deploymentBased on the exhibit, what should the administrator configure so the container group can pull the private image without storing registry credentials?
⚠ Common exam trap
Test-takers frequently confuse SAS tokens (used for Azure Storage) with ACR authentication, or assume that resource group placement or admin credentials are valid solutions, when the core requirement is to use Azure AD-based authentication via a managed identity to avoid storing any credentials.
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
✓
Assign a managed identity to the container group and grant it AcrPull on the registry.
Azure Container Groups support managed identities, which allow the container group to authenticate to Azure Container Registry (ACR) without storing any credentials. By assigning a system-assigned or user-assigned managed identity to the container group and granting it the AcrPull role on the registry, the container runtime can use Azure AD authentication to pull the private image. This eliminates the need to store registry admin credentials or SAS tokens in the container configuration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Assign a managed identity to the container group and grant it AcrPull on the registry.
Why this is correct
Managed identity-based access is the correct secret-free method for Azure Container Instances to authenticate to Azure Container Registry. By assigning an identity to the container group and granting that identity the AcrPull role on the registry, the group can pull the private image without storing credentials in the template. This satisfies both security and operational requirements.
- ✗
Store the ACR admin account password in a container environment variable.
Why it's wrong here
The ACR admin account is a registry-wide shared credential that is disabled by default and grants full administrative permissions to the registry, not least-privilege access. Placing that password in a container environment variable embeds the secret in clear text in the container group's configuration and still counts as storing credentials on the deployment, directly violating an explicit 'no stored credentials' requirement. ACI does not encrypt environment variables at rest, and rotating the admin password would require redeploying the container group.
When this WOULD be correct
This option would be correct if the question asked for a simple way to authenticate to ACR for testing purposes, without requiring managed identities or key vault, and security concerns were not a factor.
- ✗
Use a SAS token for the container image reference.
Why it's wrong here
A SAS token grants delegated access to specific Azure Storage resources, and while Azure Container Registry supports SAS for certain blob operations, it is not a valid authentication mechanism for the Docker Registry HTTP API that ACI uses to pull images. For a private ACR image, ACI must obtain an ACR refresh token by exchanging credentials (admin password, service principal, or a managed identity token), not by presenting a SAS URI in the image reference. A SAS token also expires and, if embedded in the image reference, would be visible in the container group definition without aligning to ACR's token flow.
When this WOULD be correct
If the question were about accessing a private container image stored in Azure Blob Storage (e.g., using a custom container runtime), a SAS token on the image reference would provide temporary access without storing credentials.
- ✗
Place the registry in the same resource group as the container group.
Why it's wrong here
Co-locating the registry and container group in the same resource group only affects management grouping, billing, and RBAC inheritance at that scope; it does not grant the Azure Container Instances service permission to read the private image. ACI's infrastructure runs on shared nodes that need explicit authorization to the registry, which is accomplished by assigning an RBAC role such as AcrPull to a managed identity, not by changing deployment topology. Without that role assignment, the pull fails even when both resources live in the same resource group.
When this WOULD be correct
If the question asked about minimizing cross-resource group costs or simplifying resource management, placing resources in the same resource group could be correct. For example, 'What should an administrator do to reduce network egress costs between a container registry and a container group?'
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.
✓Assign a managed identity to the container group and grant it AcrPull on the registry.Correct answer▾
Why this is correct
Managed identity-based access is the correct secret-free method for Azure Container Instances to authenticate to Azure Container Registry. By assigning an identity to the container group and granting that identity the AcrPull role on the registry, the group can pull the private image without storing credentials in the template. This satisfies both security and operational requirements.
✗Store the ACR admin account password in a container environment variable.Wrong answer — click to see why▾
Why this is wrong here
Storing the ACR admin account password in a container environment variable exposes credentials in plain text, which violates security best practices and does not meet the requirement of 'without storing registry credentials.'
★ When this WOULD be the correct answer
This option would be correct if the question asked for a simple way to authenticate to ACR for testing purposes, without requiring managed identities or key vault, and security concerns were not a factor.
Why candidates choose this
Candidates may think environment variables are a secure way to pass secrets, or they may be unaware of managed identity as a more secure alternative for Azure resources.
✗Use a SAS token for the container image reference.Wrong answer — click to see why▾
Why this is wrong here
A SAS token is used for granting time-limited access to Azure Storage resources, not for authenticating to Azure Container Registry. Container groups pull images using registry credentials, not SAS tokens.
★ When this WOULD be the correct answer
If the question were about accessing a private container image stored in Azure Blob Storage (e.g., using a custom container runtime), a SAS token on the image reference would provide temporary access without storing credentials.
Why candidates choose this
Candidates may confuse SAS tokens with other access methods, thinking they can be used for any Azure resource, or they may recall that SAS tokens are used for secure access without credentials in storage scenarios.
✗Place the registry in the same resource group as the container group.Wrong answer — click to see why▾
Why this is wrong here
Placing the registry in the same resource group as the container group does not grant any authentication permissions; the container group still needs credentials to pull a private image.
★ When this WOULD be the correct answer
If the question asked about minimizing cross-resource group costs or simplifying resource management, placing resources in the same resource group could be correct. For example, 'What should an administrator do to reduce network egress costs between a container registry and a container group?'
Why candidates choose this
Candidates may mistakenly believe that same resource group implies automatic access or trust, confusing resource group scope with actual authentication mechanisms.
Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Dynamic Membership Groups
Key term
SAS
SAS (Serial Attached SCSI) is a high-speed data transfer technology used to connect hard drives and SSDs in servers and enterprise storage systems.
Key term
User-assigned managed identity
A user-assigned managed identity is a standalone Azure identity that can be assigned to one or more Azure resources, enabling them to authenticate to other services without storing credentials.
About these practice questions
Courseiva writes every AZ-104 question from scratch — 1,049 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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-104 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-104 exam.