SC-100 Design security solutions for infrastructure 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.

• ✗

  Enable Microsoft Entra ID integration for AKS.

  Why it's wrong here

  Microsoft Entra ID integration for AKS is a control-plane authentication and authorization mechanism that maps Microsoft Entra ID identities to Kubernetes RBAC roles, governing who can execute kubectl commands or view logs. It does not inspect the container images referenced in pod specifications, nor does it evaluate the registry source of those images once the user is authenticated. Because image pulling is performed by the kubelet on each node based on configured image pull secrets and the image name in the YAML, Microsoft Entra ID integration has no means to reject a pod that references an image outside your ACR. Thus, while valuable for access governance, it cannot enforce that only images from a specific ACR are used.

• ✓

  Apply an Azure Policy initiative to only allow images from a specific ACR.

  Why this is correct

  Azure Policy provides a built-in initiative for AKS that includes the 'Kubernetes cluster containers should only use allowed images' policy, which is enforced by the azurepolicy add-on acting as an admission controller. When a pod is created, the add-on intercepts the admission request, parses each container's image reference using Rego constraints, and compares the registry hostname against the allowed patterns you define in the policy parameters (e.g., yourACR.azurecr.io/*). If the image does not match the whitelist, the API server rejects the deployment before any workload is scheduled, providing a hard guarantee at the Kubernetes control plane. This is precisely the required capability: enforcing image source at pod creation time, independent of any credentials or network paths.

• ✗

  Use Azure Key Vault to store container image credentials.

  Why it's wrong here

  Azure Key Vault, when integrated with AKS through the secrets-store CSI driver, can securely mount registry credentials (such as dockerconfigjson) into the node or pod so that the kubelet can pull images from private registries without storing secrets in etcd. However, Key Vault is a secret management service; it does not act as an admission controller and has no logic to parse a container image reference or evaluate whether the registry matches an approved policy. Once the credentials are provided, the kubelet can use them to pull any image whose repository is accessible with those credentials, including lateral movement to another registry if the same secret applies. Therefore, Key Vault improves secret hygiene but does nothing to restrict which image sources are allowed.

• ✗

  Configure network policies in AKS to restrict egress traffic.

  Why it's wrong here

  Network policies in AKS, whether using Calico or Azure Network Policy, control traffic flows at the IP address, port, and label level by modifying iptables or similar data-plane rules on the node; they do not intercept or evaluate Kubernetes API requests or pod manifest contents. Image pulls originate from the kubelet to the external registry over the node's network interface, and a network policy that restricts egress could potentially block the ACR endpoint—but such a block would be a blanket deny, not a selective allow based on registry identity, and it would also break any other egress the cluster requires. Even if you allowed network traffic to your specific ACR IP, nothing would stop a user from specifying an image with the same registry hostname but a different repository, or using a private endpoint to another registry on the same allowed CIDR. Network policy operates at a lower layer and cannot parse image digests, tags, or registry paths, so it cannot enforce an image source allowlist; it is not a substitute for admission control.

Go deeper

Related to this question