AZ-500 Secure compute, storage, and databases Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  AKS managed identity

  Why it's wrong here

  Using the AKS cluster's managed identity to pull from ACR grants registry access at the cluster level, meaning any workload running on any node in the cluster can potentially use that identity to obtain images. This violates the policy requiring the use of a dedicated service principal secret, because a managed identity is not a static service principal secret and lacks the per-pod scoping needed to limit access to specific workloads. Worse, a cluster-scoped identity amplifies the blast radius if the cluster or a node is compromised, as the credential is not easily revocable per workload.

• ✗

  ACR admin account

  Why it's wrong here

  The ACR admin account is a static, shared username and password that carries full registry permissions, including push and delete, far beyond the read-only access needed to pull images. Because it is a single credential with no per-registry or per-repository scoping, any secret leak exposes the entire registry, and the lack of built-in rotation and auditing mechanisms makes it unsuitable for production. A service principal with the AcrPull role would provide a narrowly scoped, independently rotatable credential, which is why the admin account fails the least-privilege and secret-management requirements.

• ✓

  Kubernetes pull secret using a service principal

  Why this is correct

  To implement this, create a service principal with only the AcrPull role, use its app ID and password as the username and password fields, and store the base64-encoded Docker config in a Kubernetes secret of type `kubernetes.io/dockerconfigjson`. Reference that secret in a pod's `imagePullSecrets` so the kubelet uses it to authenticate only for the pods that declare it, limiting access to those specific workloads. This credential is scoped to the service principal and can be rotated or revoked independently without affecting the cluster's control-plane identity, making it the correct choice when the policy explicitly demands a service principal secret instead of an identity-based assignment.

• ✗

  Microsoft Entra ID pod identity

  Why it's wrong here

  Microsoft Entra ID Pod Identity assigns an Microsoft Entra ID managed identity to individual pods, enabling them to request a token and authenticate to ACR via `az acr login` or token-based pulls; however, this is fundamentally an identity-based mechanism, not a static service principal secret stored in a Kubernetes pull secret. Introducing it for image pulls would require deployed components like NMI (Node Managed Identity) and MIC (Managed Identity Controller), adding complexity and operational overhead while still violating the stated requirement to use a service principal secret. Additionally, the policy specifically forbids using any cluster or pod identity for this purpose, so this approach is not merely suboptimal—it is non-compliant by design.

Go deeper

Related to this question