AZ-104 Deploy and Manage Azure Compute Practice Question
A container group in Azure Container Instances must pull a private image from Azure Container Registry without embedding registry credentials in the template. What should you configure?
⚠ Common exam trap
Candidates often confuse network access controls (like 'Allow Azure Services' or service endpoints) with authentication mechanisms, assuming that enabling network rules alone grants pull access, when in fact a managed identity with AcrPull is required for credential-free authentication.
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
✓
A managed identity for the container group and the AcrPull role on the registry
Azure Container Instances (ACI) can authenticate to Azure Container Registry (ACR) using a managed identity assigned to the container group. By granting the managed identity the AcrPull role on the registry, ACI can pull private images without embedding any credentials in the deployment template, leveraging Azure AD authentication and RBAC for secure access.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
A managed identity for the container group and the AcrPull role on the registry
Why this is correct
A user-assigned or system-assigned managed identity provides the container group with an Azure AD-backed identity that ACR accepts for authentication, entirely avoiding embedded secrets. The identity must be explicitly assigned the AcrPull role on the registry so the container group has permission to pull the image; without that role, ACR rejects the token despite a valid identity. This is the recommended and only credential-free method for ACI-to-ACR authentication.
- ✗
An admin user account on the Azure Container Registry
Why it's wrong here
Enabling the admin user account on a registry creates a static, high-privilege username and password pair that can access the entire registry. Placing those credentials in the container group definition embeds secrets, which the question explicitly says to avoid, and grants broad registry access rather than least-privilege scoped to pull actions. Microsoft's guidance is to use managed identities instead, as admin credentials are intended only for legacy or non-production scenarios and require manual rotation.
When this WOULD be correct
If the question asked for the simplest way to authenticate to a container registry without requiring Azure AD integration or managed identities, enabling the admin user and using its credentials would be correct.
- ✗
A shared access signature in a container environment variable
Why it's wrong here
A shared access signature (SAS) embedded in a container environment variable is still a credential—it must be generated, stored, and rotated, and it can be leaked through the container's metadata or logs. Moreover, ACI's native ACR integration does not use SAS tokens for image pull authentication; ACR image pulls accept Azure AD tokens or registry admin credentials, not blob-style SAS signatures. This approach violates the no-secrets-in-credentials requirement and is not a supported pattern for ACI pulling from ACR.
When this WOULD be correct
This option would be correct if the question asked about accessing a private container image stored in Azure Blob Storage (not ACR) using a SAS token passed as an environment variable. For example: 'A container group needs to download a private container image from Azure Blob Storage. What should you configure?'
- ✗
A public network access rule that allows all Azure services
Why it's wrong here
A public network access rule that allows all Azure services opens the ACR firewall to traffic from any Azure IP, but it grants no authentication or authorization. ACR still requires an identity or credential for pull operations; anonymous pull is disabled by default, so opening the network path alone leaves the pull request unauthorized. Network rules control connectivity, not identity, and therefore cannot be the sole mechanism for pulling a private image.
When this WOULD be correct
This option would be correct if the question asked how to allow a container group to pull an image from a registry that has public network access disabled, but the container group needs to connect from within the same Azure region or via a service endpoint.
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.
✓A managed identity for the container group and the AcrPull role on the registryCorrect answer▾
Why this is correct
A user-assigned or system-assigned managed identity provides the container group with an Azure AD-backed identity that ACR accepts for authentication, entirely avoiding embedded secrets. The identity must be explicitly assigned the AcrPull role on the registry so the container group has permission to pull the image; without that role, ACR rejects the token despite a valid identity. This is the recommended and only credential-free method for ACI-to-ACR authentication.
✗An admin user account on the Azure Container RegistryWrong answer — click to see why▾
Why this is wrong here
Using an admin user account embeds credentials in the template or requires manual entry, which violates the requirement to avoid embedding registry credentials.
★ When this WOULD be the correct answer
If the question asked for the simplest way to authenticate to a container registry without requiring Azure AD integration or managed identities, enabling the admin user and using its credentials would be correct.
Why candidates choose this
Candidates may think admin accounts are the standard way to authenticate to ACR, not realizing that managed identities provide a more secure, credential-free method.
✗A shared access signature in a container environment variableWrong answer — click to see why▾
Why this is wrong here
A shared access signature (SAS) is used to grant limited access to Azure resources like storage blobs, not to authenticate a container group to pull images from Azure Container Registry. The question requires pulling a private image without embedding credentials, which is achieved via managed identity and AcrPull role, not SAS.
★ When this WOULD be the correct answer
This option would be correct if the question asked about accessing a private container image stored in Azure Blob Storage (not ACR) using a SAS token passed as an environment variable. For example: 'A container group needs to download a private container image from Azure Blob Storage. What should you configure?'
Why candidates choose this
Candidates may confuse SAS tokens with a method to grant access to private resources, not realizing that SAS is for storage accounts (blobs, files) and not for authenticating to Azure Container Registry, which requires Azure AD authentication or admin credentials.
✗A public network access rule that allows all Azure servicesWrong answer — click to see why▾
Why this is wrong here
Configuring a public network access rule that allows all Azure services does not address authentication for pulling a private image; it only controls network access, not identity-based authorization.
★ When this WOULD be the correct answer
This option would be correct if the question asked how to allow a container group to pull an image from a registry that has public network access disabled, but the container group needs to connect from within the same Azure region or via a service endpoint.
Why candidates choose this
Candidates may think that allowing all Azure services is a simple way to grant access, confusing network-level access with authentication and authorization requirements.
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?”
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
Learn chapter
Privileged Identity Management (PIM)
Key term
Container
A container is a lightweight, standalone software package that includes everything needed to run an application, such as code, runtime, system tools, and libraries.
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.
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.