AZ-104 Deploy and Manage Azure Compute Practice Question
A container group must run an image from a private Azure Container Registry without embedding registry credentials in the deployment. The same authentication method should be reusable by future container groups, and the application must continue to work if the container group is recreated. Which identity approach should the administrator use?
⚠ Common exam trap
It's easy for candidates to choose system-assigned managed identity (A) because it is simpler to configure, but they overlook the requirement for reusability across container group recreations, which only a user-assigned managed identity can satisfy due to its independent lifecycle.
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 user-assigned managed identity assigned to the container group.
A user-assigned managed identity (B) is the correct approach because it is a persistent Azure AD identity that can be pre-created and assigned to any number of container groups. It decouples the identity from the container group's lifecycle, so if the container group is recreated, the same identity can be reassigned without reconfiguration. The container group uses this identity to authenticate to ACR via Azure AD token-based authentication, eliminating the need to embed registry credentials.
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 system-assigned managed identity for the container group.
Why it's wrong here
A system-assigned managed identity is tied to the container group's lifecycle: it is created with the resource and permanently deleted when the container group is removed. This means every new deployment gets a brand-new identity, breaking the ability to reuse a single, pre-provisioned identity across multiple container groups or future workloads. Even though it can pull from ACR when assigned AcrPull, the lack of reusability makes it inappropriate when the same identity must be consistent across deployments.
- ✓
A user-assigned managed identity assigned to the container group.
Why this is correct
A user-assigned managed identity can be reused across container groups and survives recreation of the workload resource. After granting the identity AcrPull on the registry, the container group can authenticate without stored usernames, passwords, or registry secrets.
- ✗
An ACR admin username and password stored in the container image.
Why it's wrong here
Storing the ACR admin username and password inside the container image embeds long-lived secrets directly in the artifact, which is a severe security risk if the image is pushed to a public registry or shared. The admin account is intended for emergency break-glass access, not for routine automation, and it cannot be scoped to a single repository or container group. Rotating these credentials forces you to rebuild and re-push the image, creating operational overhead and violating the principle of avoiding credential management in code.
When this WOULD be correct
A question that asks for the simplest way to authenticate to ACR for a single container group where credential rotation is not a concern and the deployment is temporary or non-production. For example: 'You need to quickly test a container image from a private ACR. Which authentication method requires minimal setup?'
- ✗
A shared access signature token passed as an environment variable.
Why it's wrong here
A shared access signature token is still a secret in string form, and passing it as an environment variable exposes it to anyone who can inspect the container group's configuration or logs. SAS tokens are time-bound and require periodic regeneration, which adds management complexity and risks downtime if the token expires mid-deployment. Most importantly, SAS is not the native Azure identity-based authentication method for pulling from ACR, and using it would require additional docker login logic inside the container, defeating the goal of a secret-free, identity-driven pull.
When this WOULD be correct
A question where a container group needs temporary, scoped access to a specific Azure resource (e.g., a storage blob) and the credentials can be refreshed on each deployment, with no requirement for persistence across recreation.
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 user-assigned managed identity assigned to the container group.Correct answer▾
Why this is correct
A user-assigned managed identity can be reused across container groups and survives recreation of the workload resource. After granting the identity AcrPull on the registry, the container group can authenticate without stored usernames, passwords, or registry secrets.
✗An ACR admin username and password stored in the container image.Wrong answer — click to see why▾
Why this is wrong here
ACR admin credentials are shared secrets that must be embedded in deployment, violating the requirement to avoid embedding credentials. They are not reusable across container groups without re-exposing the secret, and recreating the container group would require re-supplying the credentials.
★ When this WOULD be the correct answer
A question that asks for the simplest way to authenticate to ACR for a single container group where credential rotation is not a concern and the deployment is temporary or non-production. For example: 'You need to quickly test a container image from a private ACR. Which authentication method requires minimal setup?'
Why candidates choose this
Candidates may be familiar with ACR admin accounts as a straightforward way to pull images, and they might overlook the security and reusability constraints specified in the question.
✗A shared access signature token passed as an environment variable.Wrong answer — click to see why▾
Why this is wrong here
A shared access signature (SAS) token provides time-limited access and must be regenerated if the container group is recreated, violating the requirement that the authentication method be reusable and persist across recreation.
★ When this WOULD be the correct answer
A question where a container group needs temporary, scoped access to a specific Azure resource (e.g., a storage blob) and the credentials can be refreshed on each deployment, with no requirement for persistence across recreation.
Why candidates choose this
Candidates may think SAS tokens are a secure way to avoid embedding credentials, but overlook the requirement for reusability and persistence when the container group is recreated.
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
Managed identity
A managed identity is an automatically managed service principal in Azure that allows your code to authenticate to any service that supports Azure AD authentication without storing credentials.
Key term
Container registry
A container registry is a centralized storage and distribution system for container images, enabling developers to push, pull, and manage versions of application snapshots across environments.
About these practice questions
One of 1,049 original AZ-104 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 →
Same concept, more angles
1 more way this is tested on AZ-104
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. 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?
medium- ✓ A.A managed identity for the container group and the AcrPull role on the registry
- B.An admin user account on the Azure Container Registry
- C.A shared access signature in a container environment variable
- D.A public network access rule that allows all Azure services
Why A: 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.
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.