Develop Containerized Solutions on Azure practice questions

Answer: A) Run az aks update --attach-acr so the kubelet managed identity is granted the AcrPull role on the registry

AKS–ACR integration (az aks create/update --attach-acr) gives the kubelet managed identity the AcrPull role, so nodes pull images using Entra identity and no registry credentials are stored. For ABAC-enabled registries, assign the Container Registry Repository Reader role instead.

• ACorrect. The --attach-acr integration assigns the AcrPull role to the kubelet managed identity, which is the identity tied to the cluster's agent pool. Nodes then pull images with that identity, so no username, password, or pull secret needs to be stored.
• BIncorrect. This works, but it stores a shared registry credential as a Kubernetes secret, which is exactly what the team wants to avoid. It also relies on the admin account instead of Entra identity.
• CIncorrect. A scoped token limits access to specific repositories, but its password still has to be stored as a Kubernetes secret and rotated, so it doesn't meet the no-stored-credential requirement.
• DIncorrect. Image pulls on the nodes are performed by the kubelet identity, not the control-plane identity. AcrPush also grants more permission than a pull-only workload needs.

Answer: A) Consumption bills per-replica resource usage and can scale to zero; Dedicated bills per running profile instance plus a fixed plan management cost

Workload profiles environments are now the default and support both plans. The Consumption profile bills per-replica usage and can scale to zero. Dedicated profiles bill per running instance plus a fixed plan management cost for the environment.

• ACorrect. Consumption profiles are serverless: you pay only for the resources your running apps use, and they can scale to zero. Under the Dedicated plan you pay a fixed plan management cost for the whole environment, plus a variable cost based on the number of running profile instances and their resources.
• BIncorrect. This swaps the two models. The fixed plan management cost belongs to the Dedicated plan, and per-replica usage billing belongs to the Consumption profile.
• CIncorrect. Consumption profiles are billed per replica, not per node. Serverless GPU profiles (for example Consumption-GPU-NC8as-T4) are also available in supported regions, so Dedicated isn't the only GPU option.
• DIncorrect. Every workload profiles environment includes a default Consumption profile. Apps can run on Consumption, Dedicated, or both in the same environment.

Answer: A) Azure Backup for AKS, using the Backup extension in the cluster and a Backup vault

Azure Backup for AKS uses the in-cluster Backup extension and a Backup vault to back up both cluster state and CSI-based persistent volumes on a schedule. It can restore a namespace or a whole cluster to the original cluster or another one. Disk snapshots, registry geo-replication and Site Recovery each cover only part of the need or a different need.

• ACorrect. Azure Backup for AKS uses the Backup extension installed in the cluster and a Backup vault to run scheduled backups based on a backup policy. Each backup stores the cluster state in a blob container and takes snapshots of the CSI-based Azure Disk and Azure Files (SMB) persistent volumes. You can restore a namespace or the whole cluster, to the original cluster or to a different one.
• BIncorrect. Disk snapshots protect only the volume data. They don't capture the cluster's Kubernetes resources, such as deployments, services, config maps and PVC definitions. They also don't give you namespace-level or whole-cluster restore.
• CIncorrect. Registry geo-replication copies container images across regions. It doesn't back up the cluster's resource definitions or the data stored on persistent volumes.
• DIncorrect. Site Recovery replicates virtual machines for disaster recovery. It doesn't capture Kubernetes resources or let you restore a namespace or a cluster. AKS backup and restore is handled by Azure Backup for AKS.

Answer: A) USER app

The Dockerfile USER instruction sets which user the container process runs as. For .NET 8 images, Microsoft recommends adding 'USER app' to run as the built-in non-root user. EXPOSE, WORKDIR and ENTRYPOINT don't change the process identity.

• ACorrect. The USER instruction sets the user that the container's process runs as. Microsoft's .NET 8 container guidance says to add 'USER app' at the end of the Dockerfile to run as the built-in non-root user.
• BIncorrect. ENTRYPOINT defines the executable that runs when the container starts. It doesn't change the user identity, so without a USER instruction the process still runs as root.
• CIncorrect. EXPOSE only documents the port the container listens on. .NET 8 images moved their default port to 8080, a non-privileged port, so that running as non-root is easier, but declaring the port doesn't switch the process away from root.
• DIncorrect. WORKDIR sets the working directory for later instructions and for the running process. It has no effect on which user the process runs as.

Answer: A) Max surge, set to a value such as 33% of the node pool

In an AKS rolling upgrade, max surge adds buffer nodes before existing nodes are cordoned and drained, so capacity is kept. Max unavailable upgrades nodes in place and reduces capacity during the upgrade.

• ACorrect. Max surge tells AKS how many buffer nodes to add before it cordons and drains existing nodes, so capacity stays the same during the upgrade. It accepts an integer or a percentage, and Microsoft recommends 33% for production node pools. It uses extra subscription quota.
• BIncorrect. Max unavailable doesn't create surge nodes. AKS cordons that many existing nodes at a time and moves their pods to the remaining nodes, which reduces capacity during the upgrade. It's intended for cases where you can't get extra quota.
• CIncorrect. Drain timeout sets how long AKS waits for pods to be evicted from a node before the upgrade stops. It doesn't add any temporary capacity.
• DIncorrect. Soak duration is a wait period after a node is drained and before AKS reimages it and moves to the next node. It gives time for health checks but doesn't add buffer nodes.

Answer: A) State management

Dapr state management keeps data in an external state store that every replica can reach, so a stateless, multi-replica service can share conversation history. Pub/sub, service invocation, and configuration handle messaging, direct calls, and settings.

• ACorrect. The state management API provides CRUD and transaction operations against a configured state store, such as Azure Cosmos DB or Redis. Because the state lives outside any single replica, every replica can read and write the same conversation history.
• BIncorrect. Pub/sub lets publisher and subscriber apps exchange messages through a broker such as Azure Service Bus. It's for asynchronous messaging and isn't a store for reading and updating per-user data.
• CIncorrect. Service invocation discovers services and makes direct calls between them with mTLS. It handles communication between services, not storing shared data.
• DIncorrect. The configuration API retrieves application configuration items, and subscribes to changes, from a configuration store. It's meant for settings, not for writing per-user conversation data during each request.

Answer: A) Enable session affinity in the container app's ingress settings

Session affinity on Container Apps ingress keeps a client on the same replica by using cookies. It requires single revision mode and HTTP ingress. Revisions, scale rules, and Dapr don't control which replica a client reaches.

• ACorrect. Session affinity (sticky sessions) uses HTTP cookies to route all of a client's requests to the same replica. It is supported in single revision mode with HTTP ingress, which matches this app. A client is moved to another replica only if the original replica is no longer available.
• BIncorrect. Revision labels and traffic splitting decide which revision receives requests. They don't pin a client to a particular replica within a revision. Session affinity is also supported only in single revision mode, so this change works against the goal.
• CIncorrect. An HTTP scale rule controls how many replicas run, based on concurrent requests. It has no effect on which replica receives a given client's next request.
• DIncorrect. Dapr service invocation handles service-to-service calls, with service discovery and retries. It doesn't keep an external client's requests on the same replica.

Answer: A) Geo-replication on a Premium SKU registry, adding a replica in each region

ACR geo-replication (Premium SKU) keeps synced replicas in multiple regions behind one global endpoint, so each AKS cluster pulls from a nearby replica. Import, ACR Tasks and zone redundancy don't provide multi-region copies of a single registry.

• ACorrect. Geo-replication creates replicas in the regions you choose and syncs pushed content to all of them automatically. Clients use one global endpoint (myregistry.azurecr.io), which routes them to the replica with the best network performance, usually the closest. You keep one set of credentials and configuration. Geo-replication requires the Premium SKU.
• BIncorrect. Import copies images between separate registries. That creates a registry with its own login server and configuration in every region, and the copies have to be kept in sync manually, which breaks the single-registry requirement.
• CIncorrect. ACR Tasks automate image builds and patching. They don't place copies of a registry in other regions, so distant clusters would still pull from the single home-region registry.
• DIncorrect. Zone redundancy protects against an outage of one availability zone within a region. All data stays in that region, so clusters in other regions still pull across long distances.

Answer: A) Multiple revision mode, with a weight set for each active revision

To send part of the traffic to a new version in Azure Container Apps, switch the app to multiple revision mode and set a weight for each active revision. Single revision mode moves all traffic to the new revision at once.

• ACorrect. In multiple revision mode, several revisions can be active at the same time, and incoming traffic is divided by the weight (percentage) given to each revision. The weights must add up to 100%. The team can start at 90/10 and change the weights over time.
• BIncorrect. Single revision mode is the default. Once the new revision is ready, all traffic moves from the old revision to the new one, and old revisions are deprovisioned automatically. There's no way to send only part of the traffic to the new version.
• CIncorrect. Deployment slots are an Azure App Service feature, not part of Azure Container Apps. In Container Apps, versions are managed as revisions, and traffic is divided between revisions by weight.
• DIncorrect. Scale rules change how many replicas a revision runs based on load. They don't control what share of incoming traffic each revision receives.

Answer: A) A system node pool tainted CriticalAddonsOnly=true:NoSchedule, with apps on user node pools

To isolate critical system pods in AKS, use a dedicated system node pool with the CriticalAddonsOnly=true:NoSchedule taint and run applications in user node pools. Quotas, limit ranges, and PDBs don't control which nodes pods are scheduled on.

• ACorrect. System node pools are meant for critical system pods and user node pools for application pods. The mode:system label only makes AKS prefer system pools for system pods. The CriticalAddonsOnly=true:NoSchedule taint is what stops application pods from being scheduled on the system pool.
• BIncorrect. A ResourceQuota limits the total resources a namespace can consume. It doesn't control which nodes pods run on, so application pods could still land on the same nodes as system pods.
• CIncorrect. A PodDisruptionBudget limits voluntary evictions, such as node drains, for the pods it selects. It doesn't separate workloads onto different nodes or protect system pods from resource contention.
• DIncorrect. A LimitRange sets default requests and limits for pods in a namespace. It doesn't move system and application pods onto separate dedicated nodes.