CCNA Containerized Ai Workloads Questions — Page 1 of 2

MCQeasy

You need to store custom AI container images in a private registry hosted within Azure. Which Azure service provides a managed Docker registry service?

A.Azure Blob Storage

B.Azure Managed Disks

C.Azure Artifacts

D.Azure Container Registry

AnswerD

Azure Container Registry provides a managed, private Docker registry within Azure, storing and versioning container images natively. It satisfies the requirement for private hosting of custom AI container images, integrating with Microsoft Entra ID for authentication and supporting geo-replication, webhooks and tasks for automated image builds.

Why this answer

Azure Container Registry (ACR) is a managed, private Docker registry service that allows you to store and manage container images and artifacts. It supports Docker and OCI images, and integrates with Azure services like AKS, App Service, and Azure Machine Learning. For AI workloads, ACR is the standard place to store custom container images used in training or inference.

Exam trap

AI-200 often tests the confusion between general storage services (Blob Storage) and specialized container registries, or between package managers (Azure Artifacts) and container registries.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage is an object storage service for unstructured data, not a Docker registry; it lacks container image management features like repositories, tags, and Docker API support. Option B is wrong because Azure Managed Disks provides block-level storage volumes for VMs, not a registry for container images. Option C is wrong because Azure Artifacts is a package management service for NuGet, npm, Maven, etc., and does not host Docker container images.

Practice this question →

MCQmedium

You are deploying an AI workload to AKS and want to ensure that pods belonging to your application are distributed across different fault domains (availability zones) for high availability. Which Kubernetes feature should you configure?

A.Resource quotas

B.Topology spread constraints

C.Node taints and tolerations

D.Horizontal Pod Autoscaler

AnswerB

Topology spread constraints let you control how pods distribute across topology domains such as zones, satisfying the availability-zone spread requirement. By setting topologyKey to the zone label and maxSkew, Kubernetes schedules replicas evenly across fault domains, preventing all pods landing in one zone.

Why this answer

Topology spread constraints let you control how pods are distributed across topology domains such as zones or nodes, using label selectors and maxSkew to enforce even spreading. By setting topologyKey to topology.kubernetes.io/zone and a maxSkew of 1, you ensure pods are spread across availability zones, providing fault tolerance if a zone fails.

Exam trap

AI-200 often tests whether candidates confuse scheduling controls — taints/tolerations, affinity, and topology spread constraints — when the requirement is specifically even distribution across fault domains.

How to eliminate wrong answers

Option A is wrong because ResourceQuotas limit aggregate CPU/memory/object counts per namespace and have nothing to do with pod placement across zones. Option C is wrong because taints and tolerations control which nodes a pod can or cannot schedule onto, but they do not enforce even distribution across fault domains. Option D is wrong because Horizontal Pod Autoscaler scales replica count based on metrics, not placement across zones.

Practice this question →

MCQhard

You are troubleshooting slow inference latency in an AI application deployed on AKS. You suspect that network packets between inference pods are traversing unnecessary hops due to overlay routing. Which CNI mode should you have chosen for optimal direct routing?

A.Azure CNI with direct pod IP routing (no overlay)

B.Kubenet with host-port mapping

C.Kubenet with basic Linux bridge

D.Azure CNI Overlay

AnswerA

Azure CNI assigns each pod a routable IP from the virtual network subnet, so pod-to-pod traffic is delivered directly without VXLAN encapsulation or overlay hops, cutting the extra latency the stem attributes to overlay routing.

Why this answer

Azure CNI with direct pod IP routing assigns each pod a routable IP from the VNet subnet, so pod-to-pod traffic is routed natively by the Azure SDN fabric without encapsulation. This eliminates the overlay tunnel (VXLAN) hops that add latency and MTU overhead. For latency-sensitive inference traffic, direct routing is the optimal CNI choice.

Exam trap

AI-200 often tests the confusion between Azure CNI Overlay (IP-conserving but encapsulated) and Azure CNI direct routing (IP-consuming but hop-free), tricking candidates who assume 'overlay' means faster.

How to eliminate wrong answers

Option B is wrong because Kubenet uses a Linux bridge and host-port mapping with NAT, forcing pod traffic through the node's network stack and adding hops and address translation. Option C is wrong because Kubenet with a basic Linux bridge still relies on the Kubenet overlay-style routing and does not give pods first-class VNet IPs, so traffic is not directly routed. Option D is wrong because Azure CNI Overlay encapsulates pod traffic in VXLAN tunnels over the underlay, which is exactly the overlay routing that introduces the extra hops the scenario wants to avoid.

Practice this question →

MCQmedium

You have an AI workload that requires persistent storage for large model checkpoints. Which storage type should you mount to an AKS pod for optimal performance?

A.Azure Disk (Premium).

B.Azure Files (Standard).

C.Ephemeral OS Disk.

D.Azure Blob Storage (container mount).

AnswerA

Azure Disk (Premium) provides SSD-backed block storage with low latency and high IOPS, satisfying the stem's requirement for persistent storage of large model checkpoints with optimal performance. It is ReadWriteOnce, so it attaches to a single pod, unlike Azure Files.

Why this answer

Azure Disk (Premium) is the correct choice because it provides low-latency, high-IOPS block storage that can be mounted as a ReadWriteOnce volume to an AKS pod via a PersistentVolumeClaim. For large model checkpoints that require fast sequential and random I/O during training or inference, Premium SSD-backed Azure Disks deliver the performance Azure Files Standard cannot match.

Exam trap

AI-200 often tests whether candidates pick Azure Files for 'persistent storage' without considering performance — the key differentiator is that block storage (Azure Disk Premium) is required for high-IOPS checkpoint workloads.

How to eliminate wrong answers

Option B is wrong because Azure Files (Standard) is SMB-based network storage with higher latency and lower IOPS, making it unsuitable for performance-sensitive checkpoint I/O. Option C is wrong because an Ephemeral OS Disk is tied to the node's lifecycle and is used for the OS, not for persistent data — it is lost when the node is deallocated. Option D is wrong because Azure Blob Storage mounted as a container (e.g., via Blob CSI driver) is object storage with higher latency and is better for read-heavy, infrequent-access workloads, not high-performance checkpoint writes.

Practice this question →

MCQmedium

You are configuring continuous deployment for an AI model container. Whenever a data scientist pushes code to a GitHub repository, you want Azure Container Registry to automatically build and tag the new container image without managing an external CI/CD build agent. What should you use?

A.Azure DevOps self-hosted build agent running on a VM

B.ACR Tasks with automated source code triggers

C.Azure Logic Apps polling GitHub webhooks

D.An AKS deployment controller pod

AnswerB

ACR Tasks with source triggers builds and tags images automatically on GitHub commits, using ACR's own managed build infrastructure. This removes the need to provision or maintain an external CI/CD build agent, matching the stated constraint.

Why this answer

ACR Tasks supports automated builds triggered by source code commits to GitHub or Azure DevOps, executing the docker build inside Azure without requiring you to manage a build agent. You configure a task with a source trigger (e.g., on commit to a branch) and ACR builds, tags, and optionally pushes the image automatically. This matches the requirement for CI/CD without external build infrastructure.

Exam trap

AI-200 often tests whether candidates know ACR Tasks is a native, agentless build service — the trap is choosing Azure DevOps or Logic Apps because 'CI/CD' is associated with those tools, missing that ACR Tasks handles the build internally.

How to eliminate wrong answers

Option A is wrong because a self-hosted Azure DevOps agent on a VM requires you to provision, patch, and manage the build VM — the opposite of 'without managing an external CI/CD build agent.' Option C is wrong because Logic Apps polling GitHub webhooks is a generic automation pattern that does not natively build or tag container images; you would still need a build engine. Option D is wrong because an AKS deployment controller pod manages workload scheduling and reconciliation inside a cluster, not source-triggered image builds.

Practice this question →

MCQeasy

Which Azure feature allows you to set up a private, internal-only container registry?

A.Azure Private Link.

B.Azure Bastion.

C.Public access with firewall rules.

D.VPN Gateway.

AnswerA

Azure Private Link provisions a private endpoint with a private IP inside your virtual network, so the registry is reachable only over the internal network and never exposed to the public internet. This delivers the internal-only access the scenario demands.

Why this answer

Azure Private Link allows you to create a private endpoint for an Azure Container Registry (ACR), which assigns a private IP address from your virtual network. This makes the registry accessible only from within your VNet or connected networks, eliminating public internet exposure. It provides internal-only access without requiring public IPs or exposing the registry to the internet.

Exam trap

AI-200 often tests the misconception that a VPN Gateway or firewall rules alone can provide internal-only access to a PaaS service, when in fact Azure Private Link is the dedicated feature for private endpoints.

How to eliminate wrong answers

Option B is wrong because Azure Bastion is a service that provides secure RDP/SSH access to virtual machines, not a mechanism for creating private endpoints for container registries. Option C is wrong because public access with firewall rules still exposes the registry to the internet, albeit with restricted IP ranges; it does not provide an internal-only private endpoint. Option D is wrong because VPN Gateway is used to establish encrypted connections between on-premises networks and Azure VNets, but it does not directly make a container registry internal-only; it only provides network connectivity, not private endpoint isolation.

Practice this question →

MCQhard

You are troubleshooting intermittent network timeout errors between microservices in an AKS cluster running an AI pipeline. You suspect that network policies are blocking required inter-pod communication. Which CNI plugin must be configured in AKS to enforce these network policies?

A.Azure CNI with Azure Network Policies or Calico enabled

B.Kubernetes standard kube-proxy in IPVS mode only

C.Azure Virtual Network NAT Gateway

D.Kubenet basic networking without network policies

AnswerA

Azure CNI alone does not enforce Kubernetes NetworkPolicy objects; enabling either Azure Network Policies or Calico as the policy engine provides the enforcement plane that filters inter-pod traffic, satisfying the requirement to block or permit specific microservice communication.

Why this answer

AKS network policies are only enforced when the cluster uses Azure CNI (or Azure CNI Overlay) with a policy engine — either Azure Network Policy Manager or Calico — enabled at cluster creation. Kubenet does not support NetworkPolicy enforcement, and kube-proxy/NAT Gateway are unrelated to pod-level policy enforcement. Therefore Azure CNI plus Azure Network Policies or Calico is the required configuration.

Exam trap

AI-200 often tests the misconception that any CNI (including kubenet) can enforce NetworkPolicy — candidates forget that AKS requires Azure CNI plus a policy engine (Azure NPM or Calico) for enforcement to actually work.

How to eliminate wrong answers

Option B is wrong because kube-proxy in IPVS mode only handles service load-balancing (ClusterIP/NodePort translation), not NetworkPolicy enforcement — it has no policy engine. Option C is wrong because Azure NAT Gateway provides outbound SNAT for subnet traffic and has nothing to do with pod-to-pod policy enforcement. Option D is wrong because kubenet is a basic overlay that does not support NetworkPolicy at all; AKS explicitly requires Azure CNI (or Calico on Azure CNI) for policy enforcement.

Practice this question →

Multi-Selectmedium

You are troubleshooting an AI inference container deployed in Azure Container Apps that is failing health probes. Which TWO diagnostic tools or logs can you examine in the Azure portal to investigate the failure?

Select 2 answers

A.Log stream in the Azure portal for the container app replica

B.Azure Bastion connection to the container host VM

C.Container Apps console for interactive terminal access

D.AKS control plane audit logs

E.Azure Storage Account blob container metrics

AnswersA, C

The log stream surfaces real-time stdout and stderr from the failing replica, revealing why the readiness or liveness probe returns errors. It directly addresses the health probe failure by exposing container startup and runtime output without redeploying.

Why this answer

Option A, the Log stream in the Azure portal for the container app replica, is correct because Azure Container Apps exposes real-time stdout/stderr and system logs per replica, letting you see probe failures, application startup errors, and health endpoint responses directly. Option C, the Container Apps console for interactive terminal access, is correct because it opens a shell session inside the running container (via the platform's built-in exec capability), so you can manually curl the health endpoint, inspect environment variables, check listening ports, and verify the process is running. Option B is wrong because Azure Bastion connects to Azure VMs, not to Container Apps, which run on a managed serverless platform without a directly accessible host VM.

Option D is wrong because AKS control plane audit logs apply to Azure Kubernetes Service clusters, not to Container Apps. Option E is wrong because Azure Storage blob metrics report on storage account usage and performance, which are unrelated to container health probe failures.

Exam trap

The trap is mixing up AKS and Container Apps diagnostics: candidates may pick AKS control plane audit logs or Bastion because they sound like 'container' tools, but Container Apps has its own log stream and console surfaces.

Practice this question →

MCQeasy

Your enterprise requires that all container images deployed to Azure Kubernetes Service (AKS) must originate from approved corporate Azure Container Registries (ACRs). How can you enforce this restriction cluster-wide?

A.Configure standard Kubernetes Network Policies in the kube-system namespace

B.Configure Azure Policy for Kubernetes with the built-in initiative to restrict container registries

C.Set up ACR webhook notifications to trigger Azure Functions that delete unauthorized pods

D.Modify the kubelet configuration file on every cluster node manually

AnswerB

Azure Policy for Kubernetes applies admission control through the Gatekeeper webhook, denying pods whose images fall outside the allowed registry list. The built-in initiative enforces this cluster-wide, satisfying the requirement that only approved corporate ACRs be used.

Why this answer

Azure Policy for Kubernetes extends Gatekeeper/OPA into AKS, allowing cluster-wide admission control that blocks pods whose images do not match approved ACR patterns. The built-in initiative 'Kubernetes cluster containers should only use allowed images' enforces this at admission time, before workloads are scheduled. This is the native, declarative, auditable mechanism Microsoft provides for exactly this governance requirement.

Exam trap

AI-200 often tests the misconception that Kubernetes Network Policies can enforce image-source restrictions, when in reality only admission controllers (Azure Policy/Gatekeeper) operate at that layer.

How to eliminate wrong answers

Option A is wrong because Kubernetes Network Policies only control L3/L4 ingress/egress traffic between pods and namespaces — they have no visibility into image registry origins and cannot block a pod based on where its image came from. Option C is wrong because ACR webhooks are reactive notifications (push/delete events) and Azure Functions deleting pods after the fact is a remediation hack, not enforcement — unauthorized images would still run before deletion, and the approach is fragile and non-declarative. Option D is wrong because manually editing kubelet config on every node is unsupported in AKS (nodes are managed and reimaged), does not scale, and kubelet itself does not enforce image-source allowlists.

Practice this question →

MCQeasy

You are using Azure Container Apps. You need to deploy a new version of your AI model without downtime. Which deployment strategy should you configure?

A.Traffic splitting between revisions.

B.Overwrite the current revision.

C.Rolling update.

D.Scale to zero and redeploy.

AnswerA

Traffic splitting routes a percentage of requests to the new revision while the old revision still serves traffic, enabling gradual rollout and rollback without downtime. This directly satisfies the no-downtime constraint, unlike single-revision or recreate strategies that briefly interrupt service.

Why this answer

Azure Container Apps supports multiple revisions and allows you to split incoming traffic between them by percentage or label. By deploying the new model as a new revision and gradually shifting traffic, you achieve zero-downtime deployment and can perform canary or blue-green releases. This is the native mechanism for safe, progressive rollout in Container Apps.

Exam trap

AI-200 often tests the assumption that Container Apps behaves like AKS with rolling updates — the trap is forgetting that Container Apps uses immutable revisions with traffic splitting, not in-place rolling updates.

How to eliminate wrong answers

Option B is wrong because overwriting the current revision causes an in-place update that can interrupt running requests and provides no rollback path. Option C is wrong because Azure Container Apps does not expose a Kubernetes-style 'rolling update' primitive; revision-based traffic splitting is the supported pattern. Option D is wrong because scaling to zero and redeploying causes downtime and cold-start latency, defeating the no-downtime requirement.

Practice this question →

MCQmedium

You have an Azure Container Registry and an Azure Kubernetes Service cluster in different Azure regions. You want to ensure that AKS nodes pull container images from a local regional endpoint to minimize latency and cross-region data transfer fees. What feature should you configure on ACR?

A.Azure ExpressRoute global reach

B.ACR Import command scheduled daily

C.ACR Geo-Replication

D.Azure Traffic Manager DNS routing

AnswerC

ACR geo-replication creates regional replicas of the registry, so AKS nodes pull images from a local endpoint in their own region. This directly satisfies the stem's latency and cross-region data transfer constraints, unlike a single-region registry or CDN caching, which do not provide a writable local registry endpoint.

Why this answer

ACR Geo-Replication lets you replicate a registry to multiple Azure regions so that each AKS cluster pulls from a regional replica endpoint, reducing latency and eliminating cross-region egress charges. When geo-replication is enabled, ACR automatically routes pull requests to the closest replica based on the client's region. This is the native, supported way to achieve regional image locality.

Exam trap

AI-200 often tests whether candidates confuse image replication with network optimization, so the trap is choosing ExpressRoute or Traffic Manager because they sound like latency-reduction tools when the requirement is specifically a regional registry endpoint.

How to eliminate wrong answers

Option A is wrong because ExpressRoute Global Reach connects on-premises networks through Microsoft's backbone; it does not create regional ACR endpoints and is irrelevant to image pull latency between Azure regions. Option B is wrong because a scheduled ACR Import is a one-way copy operation that duplicates images but does not provide a managed regional endpoint or automatic routing, and it introduces staleness between imports. Option D is wrong because Traffic Manager is a DNS-based global load balancer for arbitrary endpoints; it does not integrate with ACR's registry endpoint model and cannot route to a registry replica.

Practice this question →

MCQhard

You need to configure network security for an Azure Container Apps environment that hosts an internal AI scoring API. The API must only be reachable from a specific Azure Virtual Network (VNet) and blocked from public internet access. How should you configure the environment?

A.Attach a Private Endpoint to the Azure Container Registry hosting the app

B.Enable IP security restrictions on the default public ingress

C.Deploy the Container Apps environment with an internal Virtual Network integration and internal load balancer

D.Configure an Azure Front Door instance with WAF rules in front of the public endpoint

AnswerC

Internal VNet integration with an internal load balancer gives the Container Apps environment a private IP address only, so the scoring API is reachable solely from within the specified Azure Virtual Network. This satisfies the stem's requirement to block public internet access while permitting VNet-only connectivity.

Why this answer

To make a Container Apps environment reachable only from a specific VNet and block public internet access, you deploy the environment with VNet integration and configure it to use an internal load balancer. This gives the environment a private IP in your subnet and removes the public ingress endpoint entirely.

Exam trap

AI-200 often tests whether candidates confuse securing the container registry (image supply chain) with securing the running app's network ingress — candidates pick Private Endpoint on ACR thinking it isolates the API, when it only isolates image pulls.

How to eliminate wrong answers

Option A is wrong because a Private Endpoint on Azure Container Registry only secures image pulls from the registry — it does nothing to control inbound access to the running Container App. Option B is wrong because IP security restrictions on public ingress still expose a public endpoint and only filter by source IP; they do not make the app VNet-only and are weaker than true private networking. Option D is wrong because Azure Front Door with WAF sits in front of a public endpoint and is designed for internet-facing traffic — it does not restrict access to a specific VNet and actually increases public exposure.

Practice this question →

MCQeasy

You need to deploy a containerized AI model to Azure Container Apps and configure it to scale based on Azure Service Bus queue messages. Which scaler should you specify?

A.azure-blob

B.azure-service-bus

C.memory

D.cron

AnswerB

The azure-service-bus scaler reads queue or topic message counts via KEDA and drives replica count accordingly. Azure Container Apps requires this exact scaler name, so it satisfies the queue-length scaling requirement rather than CPU or HTTP concurrency triggers.

Why this answer

Azure Container Apps uses KEDA-based scaling, and the azure-service-bus scaler is the built-in KEDA scaler designed to read Service Bus queue or topic subscription message counts and scale replicas accordingly. Specifying azure-service-bus as the scale rule type with the queue name and connection metadata lets Container Apps scale in/out based on message backlog. This directly matches the requirement to scale on Service Bus queue messages.

Exam trap

AI-200 often tests whether candidates confuse KEDA scaler types, so the trap is picking a resource scaler (memory/CPU) or a generic trigger (cron) when the question explicitly names an external event source like Service Bus.

How to eliminate wrong answers

Option A is wrong because azure-blob scales on Azure Blob Storage events or queue length for blob-triggered workloads, not Service Bus queues. Option C is wrong because memory is a resource-utilization scaler that reacts to container memory consumption, not external message queue depth. Option D is wrong because cron is a time-based schedule scaler that scales on a fixed timetable, not on Service Bus message volume.

Practice this question →

MCQmedium

You are managing an Azure Kubernetes Service (AKS) cluster that runs high-throughput AI model training jobs using NVIDIA Tensor Core GPUs. Pods frequently fail to schedule because of insufficient GPU memory across existing nodes. You need to ensure the cluster automatically provisions new GPU-enabled worker nodes when resource demands increase. What should you configure?

A.Configure KEDA (Kubernetes Event-driven Autoscaling) with a Prometheus scaler.

B.Configure the Horizontal Pod Autoscaler (HPA) with custom GPU metrics.

C.Enable the Kubernetes Cluster Autoscaler on a node pool containing GPU virtual machine sizes.

D.Deploy the Azure Container Storage operator with GPU caching enabled.

AnswerC

The Cluster Autoscaler watches for unschedulable pods and scales the GPU node pool out, provisioning new GPU virtual machine nodes when capacity is insufficient. This directly resolves pending training pods caused by exhausted GPU memory across existing nodes.

Why this answer

The Kubernetes Cluster Autoscaler watches for pods that cannot be scheduled due to insufficient resources and automatically scales the node pool up or down. When configured on a node pool that contains GPU-enabled VM sizes (such as NC or ND series), it will provision additional GPU nodes when training pods are pending due to GPU memory constraints. This is the only option that adds new worker nodes rather than scaling existing pods or reacting to events.

Exam trap

AI-200 often tests the confusion between pod-level autoscaling (HPA/KEDA) and node-level autoscaling (Cluster Autoscaler) — candidates pick HPA or KEDA thinking it will 'add capacity,' but only the Cluster Autoscaler provisions new nodes.

How to eliminate wrong answers

Option A is wrong because KEDA scales workloads (pods/deployments) based on event sources like Prometheus metrics — it does not provision new nodes, so pending pods would remain unschedulable. Option B is wrong because HPA scales the number of pod replicas based on metrics, but if no node has free GPU capacity, additional replicas simply stay Pending. Option D is wrong because Azure Container Storage provides persistent storage and caching for containers; it has nothing to do with node provisioning or GPU scheduling.

Practice this question →

Multi-Selectmedium

You are troubleshooting an AI application container in an AKS cluster that cannot resolve external domain names (e.g., huggingface.co). Which TWO Kubernetes components should you investigate?

Select 2 answers

A.kube-dns service endpoint mapping

B.Horizontal Pod Autoscaler configuration

C.Persistent Volume Claim binding state

D.Ingress controller SSL certificate expiration

E.CoreDNS deployment and pod health in the kube-system namespace

AnswersA, E

The kube-dns service must map to healthy CoreDNS pod endpoints; if the endpoint list is empty or points to terminated pods, name resolution fails cluster-wide. Checking the service's endpoint mapping confirms traffic reaches a live resolver.

Why this answer

Option A (kube-dns service endpoint mapping) is correct because in AKS the kube-dns Service in kube-system is the ClusterIP endpoint that pods use for DNS queries; if its selector does not match the CoreDNS pods, the endpoint list is empty and name resolution fails. Option E (CoreDNS deployment and pod health in the kube-system namespace) is correct because CoreDNS pods actually serve DNS; if they are crashlooping, unready, or scaled to zero, external names like huggingface.co cannot be resolved. Option B is irrelevant because the Horizontal Pod Autoscaler only adjusts replica counts based on metrics and has no role in DNS resolution.

Option C is irrelevant because PVC binding affects storage mounting, not name resolution. Option D is irrelevant because an expired Ingress TLS certificate only breaks HTTPS trust for inbound traffic, not outbound DNS lookups from the container.

Exam trap

AI-200 often tests whether candidates can distinguish DNS-layer failures from other pod failures, so the trap is selecting storage or autoscaling components because they are common AKS troubleshooting topics, even though the symptom is specifically name resolution.

Practice this question →

MCQmedium

You are deploying a containerized AI application to Azure Container Instances (ACI). The application needs to pull the container image from a private Azure Container Registry (ACR). You want to authenticate ACI to ACR without embedding credentials in the deployment configuration. What should you do?

A.Store the ACR credentials in Azure Key Vault and reference them in the ACI deployment using a secret volume.

B.Use the ACR admin account username and password in the ACI deployment YAML.

C.Enable the ACI system-assigned managed identity and grant it the AcrPull role on the ACR.

D.Configure ACI to use a public container image instead, avoiding the need for authentication.

AnswerC

Azure Container Instances supports system-assigned managed identities. By enabling a managed identity on the container group and assigning it the AcrPull role on the Azure Container Registry, ACI can authenticate to ACR without storing credentials. This is a secure, recommended approach for accessing private registries.

Why this answer

To authenticate ACI to ACR without embedding credentials, you should use a managed identity. Enabling a system-assigned managed identity on the container group and granting it the AcrPull role on the ACR allows ACI to pull images securely. This eliminates the need to store credentials in the deployment configuration and follows the principle of least privilege.

Exam trap

The trap here is assuming that storing credentials in Key Vault or using admin accounts is acceptable, when managed identities provide a more secure and native authentication method.

Practice this question →

MCQmedium

You are managing an AKS cluster running resource-intensive AI training jobs. You want to ensure that nodes automatically scale up and down based on pending pod resource requests. Which component should you enable and configure?

A.KEDA (Kubernetes Event-driven Autoscaling)

B.Azure Load Balancer

C.Horizontal Pod Autoscaler

D.Kubernetes Cluster Autoscaler

AnswerD

The Cluster Autoscaler watches for pods that cannot be scheduled due to insufficient node resources and adds nodes to the node pool, then removes underused ones. This directly satisfies the stem's requirement for automatic scale up and down driven by pending pod resource requests.

Why this answer

The Kubernetes Cluster Autoscaler is the component that adds or removes nodes in an AKS node pool based on pending pods that cannot be scheduled due to insufficient resources. It watches for unschedulable pods and scales the node pool up, then scales down underutilized nodes. This directly matches the requirement of scaling nodes based on pending pod resource requests.

Exam trap

AI-200 often tests the confusion between HPA (scales pods) and Cluster Autoscaler (scales nodes) — candidates pick HPA because the question mentions 'scaling' and 'resource requests' without noticing the word 'nodes'.

How to eliminate wrong answers

Option A is wrong because KEDA scales workloads (pods) based on external event sources like queues or Kafka, not the number of nodes in the cluster. Option B is wrong because Azure Load Balancer distributes traffic to pods and has no role in node provisioning or scaling. Option C is wrong because the Horizontal Pod Autoscaler adjusts replica counts of a deployment based on CPU/memory/custom metrics, but it cannot add nodes — if no node has capacity, HPA-created pods stay Pending.

Practice this question →

Multi-Selectmedium

Your development team is planning to deploy a containerized natural language processing model to Azure Container Apps. Which TWO features are natively supported by Azure Container Apps for managing application lifecycle and traffic? (Choose two.)

Select 2 answers

A.Automatic deployment of bare-metal hypervisors

B.Built-in KEDA-based autoscaling including scaling to zero

C.Native revision management and traffic splitting between revisions

D.Direct root SSH access to individual container instances for interactive debugging

E.Direct manual configuration of control plane Kubernetes master nodes

AnswersB, C

Azure Container Apps integrates KEDA scalers natively, scaling replicas on event sources such as HTTP concurrency or queue depth, and can scale to zero when idle. This satisfies the scenario's lifecycle requirement by removing manual capacity management for the NLP model.

Why this answer

Azure Container Apps natively supports KEDA-based autoscaling, including scale-to-zero, which is option B — this is a core platform capability that lets containerized workloads (such as an NLP model) scale based on event sources like HTTP traffic or queues without managing Kubernetes infrastructure. Option C is also correct because Azure Container Apps provides native revision management, allowing immutable revisions of an app to be created and traffic splitting (for example, weighted percentages) between revisions for blue-green or canary deployments. Option A is incorrect because Azure Container Apps is a serverless container platform and does not deploy or expose bare-metal hypervisors to users.

Option D is incorrect because Azure Container Apps does not provide direct root SSH access to individual container instances; debugging is done via logs, console, or exec into containers without root host access. Option E is incorrect because the Kubernetes control plane is fully managed by Azure and users cannot manually configure master nodes.

Exam trap

AI-200 often tests the misconception that Container Apps exposes Kubernetes control-plane or host-level access, when in fact it is fully abstracted and serverless.

Practice this question →

MCQhard

You are setting up image builds for a multi-architecture (AMD64 and ARM64) AI model container using Azure Container Registry Tasks. Which command or feature should you use to build images for both architectures simultaneously?

A.Azure DevOps pipeline running docker push directly

B.az aks create with --node-os-sku

C.az acr build with a multi-step task or docker buildx configuration

D.az acr import

AnswerC

Using `az acr build` with a multi-step task or buildx configuration lets ACR Tasks build AMD64 and ARM64 images concurrently, satisfying the simultaneous multi-architecture requirement. Docker Buildx creates a manifest list, while multi-step tasks orchestrate per-architecture builds in parallel within Azure, avoiding separate sequential runs.

Why this answer

Azure Container Registry Tasks supports multi-architecture image builds through `az acr build` with either a multi-step YAML task or a Dockerfile leveraging `docker buildx` for cross-platform builds (linux/amd64 and linux/arm64). ACR Tasks runs the build in Azure, so you don't need local buildx/QEMU setup, and it can push a single manifest list referencing both architecture variants. This is the native, supported path for producing multi-arch images in ACR.

Exam trap

AI-200 often tests whether candidates confuse image build orchestration (ACR Tasks/buildx) with image distribution (import) or cluster configuration (aks create), causing them to pick a command that moves or configures images rather than builds them.

How to eliminate wrong answers

Option A is wrong because an Azure DevOps pipeline running `docker push` only pushes an already-built image — it does not build for multiple architectures and lacks the buildx/multi-platform orchestration. Option B is wrong because `az aks create --node-os-sku` configures the AKS node pool OS SKU (e.g., Ubuntu, Mariner) and has nothing to do with building multi-arch container images. Option D is wrong because `az acr import` copies an existing image from another registry into ACR; it does not build anything, let alone multi-architecture images.

Practice this question →

MCQmedium

You are deploying a containerized AI model to Azure Container Apps. The model requires a GPU for inference. You configure the container app to use a workload profile with GPU support. However, when the app starts, it fails with an error indicating that the GPU is not available. You need to ensure the container can access the GPU. What should you do?

A.Set the environment variable `NVIDIA_VISIBLE_DEVICES=all` in the container app configuration.

B.Deploy the container to Azure Kubernetes Service (AKS) instead, because Azure Container Apps does not support GPU workloads.

C.Use a workload profile that includes GPU resources and ensure the container app is configured to use that profile.

D.Mount a hostPath volume from the underlying node to the container to expose the GPU device.

AnswerC

Azure Container Apps supports GPU-enabled workload profiles for specialized hardware. To access a GPU, the container app must be assigned to a workload profile that includes GPU resources, such as the `Consumption-GPU` or a dedicated GPU profile. This ensures the container is scheduled on a node with a GPU, making it available to the application.

Why this answer

Azure Container Apps provides GPU support via specialized workload profiles. To enable GPU access, you must select a workload profile that includes GPU resources and assign it to the container app. This ensures the platform schedules the container on a node with a GPU.

Other approaches like environment variables or hostPath mounts do not provision GPU hardware in this managed environment.

Exam trap

The trap here is assuming that setting environment variables or mounting devices is sufficient to access a GPU, when the platform requires a GPU-enabled workload profile.

Practice this question →

Multi-Selectmedium

Which TWO of the following steps are required to enable GPU support for a pod in AKS?

Select 2 answers

A.Use a node pool with GPU-enabled VMs.

B.Enable the 'Privileged' flag in the Dockerfile.

C.Include the 'nvidia.com/gpu' resource request in the pod.

D.Set the pod to run as root.

E.Install the NVIDIA driver on the local machine.

AnswersA, C

GPU workloads require nodes with physical NVIDIA hardware, so the AKS cluster must include a GPU-enabled node pool (such as NC or ND series VMs). The NVIDIA device plugin then exposes those GPUs as schedulable 'nvidia.com/gpu' resources.

Why this answer

Option A is correct because GPU workloads in AKS can only be scheduled onto nodes backed by GPU-enabled VM sizes (for example NC, ND, or NV series), so the cluster must contain a GPU node pool. Option C is correct because the pod spec must request the GPU resource using the extended resource name 'nvidia.com/gpu' (for example, resources.limits: nvidia.com/gpu: 1), which is how the Kubernetes device plugin advertises and allocates GPUs to the container. Option B is incorrect because the Privileged flag in a Dockerfile is unrelated to GPU enablement and is not required for GPU scheduling.

Option D is incorrect because running the pod as root is not a prerequisite for GPU access in AKS. Option E is incorrect because the NVIDIA drivers are installed and managed by AKS on the GPU nodes, not on the local client machine used to submit the pod.

Exam trap

AI-200 often tests the misconception that GPU support requires host-level driver installation or privileged containers, when in fact AKS manages drivers via the device plugin and the only pod-side requirement is the nvidia.com/gpu resource request.

Practice this question →

MCQmedium

You have a large image that takes a long time to pull. You want to speed up deployment in AKS. Which feature should you enable?

A.Use a public mirror for the image.

B.Increase the AKS node count.

C.Use smaller base images.

D.Enable Artifact Streaming in ACR.

AnswerD

Artifact Streaming in Azure Container Registry lets AKS pull only the image layers needed to start the container, rather than downloading the whole image first. This reduces startup latency for large images, directly addressing the slow pull.

Why this answer

Artifact Streaming in ACR (also called streaming artifacts) allows AKS nodes to start containers before the entire image is downloaded, by streaming only the layers needed at startup. This dramatically reduces cold-start time for large images because the kubelet doesn't wait for a full pull. It's the purpose-built ACR feature for accelerating large-image deployments in AKS.

Exam trap

AI-200 often tests the difference between build-time image optimizations (smaller base images, multi-stage builds) and registry/deployment-time acceleration features like Artifact Streaming — candidates pick 'smaller base images' because it sounds like the obvious fix, but the question asks what to enable for an already-large image.

How to eliminate wrong answers

Option A is wrong because a public mirror only changes the registry location — it doesn't change the fact that the full image must still be pulled, and it may introduce security/compliance issues. Option B is wrong because adding nodes increases capacity/parallelism but does not reduce the time to pull a single large image onto a node. Option C is wrong because using smaller base images is a build-time optimization, not a deployment-time feature you 'enable' on an existing large image.

Practice this question →

Multi-Selectmedium

Which THREE of the following are security best practices for container registries?

Select 3 answers

A.Use Private Link for network access.

B.Disable HTTPS for faster access.

C.Apply Role-Based Access Control (RBAC).

D.Use the 'latest' tag for production images.

E.Enable vulnerability scanning.

AnswersA, C, E

Private Link gives the registry a private endpoint on your virtual network, so image pulls and pushes never traverse the public internet. This satisfies the stem's network-isolation constraint by removing public exposure of the registry endpoint, blocking anonymous or internet-originated access attempts.

Why this answer

Option A is correct because using Azure Private Link (or an equivalent private endpoint) for registry access keeps traffic on the Microsoft backbone network and eliminates exposure of the registry to the public internet, preventing unauthorized access and data exfiltration. Option C is correct because applying Role-Based Access Control (RBAC) enforces least-privilege access, ensuring only authorized identities can push, pull, or manage registry resources such as repositories and images. Option E is correct because enabling vulnerability scanning (for example, Microsoft Defender for Containers or registry-integrated scanning) automatically detects known CVEs in image layers and base images, allowing remediation before deployment.

Option B is not a best practice because disabling HTTPS exposes registry credentials and image layers to man-in-the-middle attacks and tampering; registries must enforce TLS. Option D is not a best practice because the 'latest' tag is mutable and non-deterministic, so production deployments should use immutable, version-specific tags or digests to guarantee reproducibility and traceability.

Exam trap

AI-200 often tests whether candidates confuse convenience shortcuts (disabling HTTPS, using 'latest') with actual security controls, so any option that weakens transport security or reproducibility is always wrong.

Practice this question →

MCQmedium

You are deploying a containerized machine learning inference service to Azure Container Apps. The model artifact is large (15 GB) and must be securely loaded during container startup. What is the most efficient way to mount this model data into the container app?

A.Mount an Azure Files volume to the container app

B.Download the model over the public internet at container boot

C.Bake the model directly into the Docker image layer

D.Store the model in environment variables

AnswerA

Azure Files volumes mount directly into the container filesystem over SMB, so the 15 GB artifact is read at startup without being baked into the image or copied through a build step. This satisfies the stem's requirement for secure, efficient loading of large model data.

Why this answer

Mounting an Azure Files volume to the Container App is the most efficient approach because the 15 GB model is stored once in a durable share and mounted at container startup without bloating the image or re-downloading over the internet. Azure Files is the native persistent volume type for Container Apps and supports secure access via storage account keys or managed identity, satisfying the 'securely loaded' requirement.

Exam trap

AI-200 often tests whether candidates choose image-baking or internet downloads for large models — the exam expects you to recognize that persistent volume mounts (Azure Files) are the efficient, secure pattern.

How to eliminate wrong answers

Option B is wrong because downloading a 15 GB model over the public internet at every container boot is slow, unreliable, and exposes the artifact to network egress costs and potential tampering. Option C is wrong because baking a 15 GB model into the Docker image layer creates a massive image, slows every pull, wastes registry storage, and makes model updates require a full image rebuild and redeploy. Option D is wrong because environment variables are limited in size (typically a few KB) and are meant for configuration, not multi-gigabyte binary artifacts.

Practice this question →

Multi-Selecthard

You are configuring an Azure Kubernetes Service (AKS) cluster for enterprise AI workloads. Which THREE practices should you implement to enhance cluster security and isolation? (Choose three.)

Select 3 answers

A.Configure Microsoft Entra Workload Identity for pod-to-Azure service authentication

B.Disable TLS on the API server to improve inter-node communication speed

C.Share a single service principal across all namespaces for simplified administration

D.Enable Azure Policy for Kubernetes for governance and compliance enforcement

E.Integrate Microsoft Entra ID with Azure RBAC for Kubernetes authorization

AnswersA, D, E

Workload Identity federates a Kubernetes service account with a Microsoft Entra ID identity via OIDC, so pods obtain short-lived tokens instead of stored secrets. This removes long-lived credentials from the cluster, directly satisfying the isolation requirement for pod-to-Azure service authentication.

Why this answer

Option A is correct because Microsoft Entra Workload Identity federates Kubernetes service accounts with Microsoft Entra ID via OIDC, letting pods authenticate to Azure services (Key Vault, Storage, etc.) without storing secrets or using a shared service principal. Option D is correct because Azure Policy for Kubernetes (via the Gatekeeper admission controller) enforces governance and compliance at the cluster level, such as restricting privileged containers, hostPath mounts, and allowed registries. Option E is correct because integrating Microsoft Entra ID with Azure RBAC for Kubernetes authorization enables centralized, identity-based access control to the API server, replacing static local accounts and supporting least-privilege role assignments.

Option B is incorrect because disabling TLS on the API server exposes credentials and traffic to interception and violates security best practices; performance gains do not justify it. Option C is incorrect because sharing a single service principal across all namespaces eliminates isolation, creates a single credential to compromise, and prevents per-workload least-privilege scoping.

Exam trap

The trap is accepting 'simplified administration' or 'performance' justifications for insecure choices; the exam rewards least-privilege identity, policy enforcement, and centralized RBAC over convenience.

Practice this question →

MCQeasy

You need to store private AI model weights in an Azure Container Registry (ACR). Which authentication method follows the principle of least privilege for an AKS cluster to pull these images?

A.Service Principal with Contributor role.

B.ACR Admin account credentials.

C.Azure Managed Identity.

D.A shared SAS token generated for the registry.

AnswerC

Azure Managed Identity issues token-based credentials scoped to the AKS cluster's identity, so no registry passwords or service principal secrets are stored. Granting that identity only the AcrPull role on the registry satisfies least privilege, unlike admin credentials or broad subscription-level roles.

Why this answer

Azure Managed Identity lets the AKS cluster authenticate to ACR without storing any credentials, and the identity can be granted only the AcrPull role scoped to the specific registry. This satisfies least privilege because the cluster gets exactly the permission needed (pull images) and nothing more, with no secrets to rotate or leak. It is the recommended, Microsoft-supported approach for AKS-to-ACR authentication.

Exam trap

AI-200 often tests the misconception that a Service Principal with Contributor or the ACR Admin account is 'fine' for image pulls — the exam expects you to recognize that only a scoped identity (Managed Identity with AcrPull) satisfies least privilege.

How to eliminate wrong answers

Option A is wrong because a Service Principal with the Contributor role grants broad management permissions across the subscription or resource group — far more than the pull-only access required, violating least privilege. Option B is wrong because the ACR Admin account is a shared, all-powerful credential that bypasses RBAC and cannot be scoped; it is explicitly discouraged for production. Option D is wrong because ACR does not issue SAS tokens for image pulls — SAS is an Azure Storage concept, and using it here reflects a fundamental misunderstanding of ACR authentication mechanisms.

Practice this question →

MCQeasy

You are building an AI container image and need to minimize its final size to speed up deployment times. Which multi-stage build practice should you follow?

A.Use a builder stage for compilation and copy only runtime artifacts into a slim base image

B.Store model weights directly inside the container image layers

C.Install all development tools and pip packages in a single RUN instruction

D.Disable container image compression when pushing to ACR

AnswerA

A multi-stage build compiles dependencies in a builder stage, then copies only the runtime artefacts into a slim base image, excluding compilers, caches and build tooling. This directly satisfies the stem's constraint of minimising final image size to accelerate deployment.

Why this answer

Multi-stage builds use a builder stage containing compilers, SDKs, and build dependencies, then copy only the compiled artifacts (binaries, wheels, model files needed at runtime) into a minimal runtime base image such as python:3.11-slim or alpine. This keeps the final image free of build toolchains, caches, and intermediate layers, dramatically reducing image size and pull time. The other options either bloat the image or are unrelated to build strategy.

Exam trap

AI-200 often tests whether candidates confuse 'fewer layers' (a Dockerfile optimization) with 'smaller final image' (which requires multi-stage builds to exclude build-time dependencies).

How to eliminate wrong answers

Option B is wrong because baking model weights into image layers inflates the image by gigabytes and prevents independent updates of models versus code. Option C is wrong because combining all installs into one RUN may reduce layer count but does not remove dev tools or pip caches, so the image stays large; multi-stage is what actually strips build-time dependencies. Option D is wrong because disabling compression increases the pushed artifact size and slows pulls — it does not reduce the image itself and hurts deployment speed.

Practice this question →

Multi-Selecthard

You are configuring rolling updates for an AI model inference service on AKS with zero downtime requirements. Which THREE deployment or pod configuration settings should you configure?

Select 3 answers

A.Deployment strategy set to RollingUpdate with configured maxSurge and maxUnavailable

B.Readiness and liveness probes to verify container health before traffic routing

C.Setting restart policy to Never on the Deployment template

D.Pod Disruption Budget (PDB) to ensure minimum available replicas during node drains

E.Disabling all container health checks to speed up pod termination

AnswersA, B, D

RollingUpdate with tuned maxSurge and maxUnavailable governs how many pods are added above desired count and how many may be unavailable during the rollout. Setting maxUnavailable to zero guarantees capacity never dips, satisfying the zero-downtime constraint.

Why this answer

Option A is correct because a Deployment with strategy RollingUpdate and tuned maxSurge/maxUnavailable parameters replaces pods incrementally, ensuring new replicas become available before old ones are terminated, which is essential for zero-downtime rollouts. Option B is correct because readiness probes gate Service endpoint membership so traffic only reaches containers that are actually ready, while liveness probes restart hung containers, both preventing failed pods from serving inference requests. Option D is correct because a Pod Disruption Budget enforces a minimum number of available replicas during voluntary disruptions such as node drains or upgrades, protecting capacity while nodes are cordoned.

Option C is incorrect because restartPolicy Never is only valid for standalone Pods, not for Deployment-managed pods (which require Always), and it would prevent automatic recovery. Option E is incorrect because disabling health checks removes the readiness gating that zero-downtime routing depends on and can send traffic to unready or broken containers.

Exam trap

AI-200 often tests whether candidates know that restartPolicy: Never is illegal on Deployments and that removing health checks is never a valid optimization — the exam baits speed-focused answers that actually break availability.

Practice this question →

Multi-Selecthard

Which THREE of the following options are important when configuring an AKS cluster for AI workloads?

Select 3 answers

A.Network policies for pod communication isolation.

B.Always run every pod as privileged.

C.Managed identity for cluster components.

D.Disable all internal firewalls.

E.GPU-enabled node pools.

AnswersA, C, E

Network policies apply Kubernetes rules controlling which pods may exchange traffic, isolating workloads and limiting lateral movement between namespaces. This satisfies the stem's AI workload constraint, where multi-tenant training jobs and inference endpoints sharing a cluster need segmented pod communication.

Why this answer

Option A is correct because network policies (implemented via Azure Network Policy or Calico on AKS) let you isolate pod-to-pod traffic, which is essential for securing AI workloads that often handle sensitive data and expose inference endpoints. Option C is correct because managed identity lets AKS cluster components (such as the kubelet, control plane, and CSI drivers) authenticate to Azure resources like Key Vault, ACR, and Storage without embedding credentials, which is a security best practice for AI pipelines pulling models and data. Option E is correct because AI workloads such as model training and inference require GPU acceleration, and AKS supports GPU-enabled node pools (e.g., NC/ND-series VMs with NVIDIA device plugin) to schedule those workloads.

Option B is not appropriate because running every pod as privileged grants full host access and violates least-privilege, dramatically increasing the attack surface. Option D is wrong because disabling internal firewalls removes necessary network segmentation and security controls rather than properly configuring NSGs, Azure Firewall, or private endpoints.

Exam trap

AI-200 often tests the misconception that 'more privilege equals better performance' — candidates pick privileged pods or disabled firewalls thinking they remove bottlenecks, when the exam expects secure, least-privilege AI cluster design.

Practice this question →

Multi-Selectmedium

You are building a container image for an AI application that will be deployed to Azure Container Instances (ACI). The image will be stored in Azure Container Registry (ACR). You need to ensure that the image can be pulled by ACI securely without embedding registry credentials in the image or in scripts. Which TWO of the following approaches can be used to authenticate ACI to ACR? (Choose two.)

Select 2 answers

A.Enable anonymous pull on the ACR instance so that ACI can pull images without authentication.

B.Create a service principal with the AcrPull role and use its credentials in the ACI deployment.

C.Use the Azure Container Registry's built-in token authentication with a scoped token stored in the container image.

D.Assign a managed identity to the ACI container group and grant it the AcrPull role on the ACR instance.

E.Use the ACR admin account username and password stored in Azure Key Vault and referenced in the ACI deployment.

AnswersB, D

You can create an Azure AD service principal, assign it the AcrPull role on the ACR, and provide its credentials (client ID and secret) in the ACI deployment configuration. This allows ACI to authenticate to ACR. While this method works, it requires managing the service principal secret, which can be rotated. It is a valid approach, though managed identity is often preferred for Azure resources.

Why this answer

ACI can authenticate to ACR using either a managed identity with the AcrPull role or a service principal with the AcrPull role. Both methods avoid embedding credentials in the image. Managed identity is preferred for Azure resources as it eliminates secret management.

The admin account is not recommended due to broad permissions, anonymous pull is insecure, and embedding tokens in images is a security risk.

Exam trap

The trap here is thinking that the ACR admin account is a secure and recommended method, but it has full registry access and is not scoped, making it less secure than managed identity or service principal.

Practice this question →

Multi-Selecteasy

Which THREE of the following are components of a standard Dockerfile for an AI application?

Select 3 answers

A.CLUSTER_CREATE.

B.RUN (Installation of libraries/tools).

C.CMD/ENTRYPOINT (Process command).

D.FROM (Base image).

E.AZURE_LOGIN (Manual login).

AnswersB, C, D

RUN executes commands during image build, installing the Python libraries, CUDA toolkits and dependencies the AI application needs. This satisfies the build-time installation requirement, layering packages into the image before runtime rather than at container start.

Why this answer

Option D (FROM) is correct because every Dockerfile must begin with a FROM instruction that specifies the base image (e.g., FROM nvidia/cuda:12.2.0-runtime-ubuntu22.04 or FROM python:3.11-slim) on which the AI application's layers are built. Option B (RUN) is correct because RUN executes build-time commands inside the image, such as pip install torch tensorflow or apt-get install, to install the libraries and tools the AI application needs. Option C (CMD/ENTRYPOINT) is correct because these instructions define the process command that starts when the container launches, such as CMD ["python", "app.py"], which is essential for running the AI workload.

Option A (CLUSTER_CREATE) is not a Dockerfile instruction; it is a cluster-provisioning action performed by orchestration tooling, not image build syntax. Option E (AZURE_LOGIN) is not a Dockerfile instruction either; authentication to Azure is handled externally via the Azure CLI or service principals, not baked into the image build.

Exam trap

AI-200 often tests whether candidates can distinguish real Dockerfile instructions (FROM, RUN, CMD, ENTRYPOINT, COPY) from orchestration or cloud CLI commands (CLUSTER_CREATE, AZURE_LOGIN) that look plausible but are not part of the Dockerfile spec.

Practice this question →

MCQhard

You are running a GPU-intensive AI workload in AKS. You want to ensure the pods are scheduled only on nodes that have GPUs. How do you enforce this?

A.Use a DaemonSet.

B.Use a nodeSelector for 'sku=gpu'.

C.Define a Resource Request for RAM.

D.Add a Kubernetes Taint to the GPU nodes.

AnswerB

A nodeSelector in the pod spec constrains scheduling to nodes whose labels match sku=gpu, so the scheduler only places GPU pods on GPU-labelled nodes. This enforces the GPU-only placement constraint in AKS without relying on taints or affinity rules.

Why this answer

A nodeSelector in the pod spec constrains scheduling to nodes whose labels match the specified key-value pair, so 'sku=gpu' ensures the pod only lands on GPU-labeled nodes. This is the simplest and most direct scheduling constraint for hardware targeting in AKS. It works because the Kubernetes scheduler filters nodes by label before scoring them.

Exam trap

AI-200 often tests the confusion between taints (which repel pods) and nodeSelector/affinity (which attract pods) — candidates pick taints thinking they schedule workloads onto GPU nodes, when taints actually do the opposite.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures one pod per node for cluster-wide agents like log collectors; it does not target GPU nodes specifically and would run on every node. Option C is wrong because a memory resource request only influences bin-packing and eviction, not which node type the pod lands on. Option D is wrong because a taint on GPU nodes repels pods that lack a matching toleration — it prevents scheduling rather than attracting pods to GPU nodes, and by itself does not guarantee placement on them.

Practice this question →

Multi-Selecthard

You are configuring enterprise networking for an AKS cluster running sensitive AI models. Which THREE networking features should you implement for cluster security?

Select 3 answers

A.Public IP assignment to every worker node

B.Azure Firewall or user-defined routes for outbound egress filtering

C.Disabling all internal kube-dns resolution

D.Azure CNI Network Policies for pod-level traffic restriction

E.Private AKS API server endpoint

AnswersB, D, E

Azure Firewall and user-defined routes control outbound traffic from the AKS cluster, restricting egress to approved destinations. This satisfies the scenario's requirement for outbound egress filtering, preventing sensitive AI workloads from reaching unauthorised external endpoints.

Why this answer

Option B is correct because Azure Firewall or user-defined routes (UDRs) let you control and filter outbound egress traffic from the AKS cluster, preventing exfiltration of sensitive AI models and enforcing FQDN/network rules. Option D is correct because Azure CNI Network Policies enforce Kubernetes NetworkPolicy objects at the pod level, restricting east-west traffic between pods so compromised workloads cannot freely reach other services. Option E is correct because a private AKS API server endpoint exposes the control plane only via a private IP inside your VNet or peered network, removing public internet exposure of the Kubernetes API.

Option A is not appropriate because assigning public IPs to every worker node increases the attack surface and is unnecessary for secure egress. Option C is not appropriate because disabling all internal kube-dns resolution would break service discovery and core cluster functionality rather than improve security.

Exam trap

AI-200 often tests whether candidates can distinguish genuine security controls from operational misconfigurations, tempting them to select options like public IPs or disabling DNS that sound like 'network changes' but actually weaken or break the cluster.

Practice this question →

MCQhard

Your containerized AI application requires a specific version of a kernel driver that is not installed on the AKS nodes. What is the most efficient way to manage this?

A.Mount the /proc filesystem as read-write.

B.Run the application as root.

C.Use a privileged InitContainer to load the driver.

D.Rebuild the AKS cluster.

AnswerC

A privileged InitContainer runs before the main application container, letting it install the required kernel driver directly onto the node's host filesystem. This satisfies the stem's constraint that the driver is missing from AKS nodes without rebuilding node images.

Why this answer

A privileged InitContainer runs before the main application container and, with privileged security context, can load kernel modules (e.g., via modprobe or insmod) onto the node. This is the standard Kubernetes pattern for node-level setup that must complete before the workload starts. It is more efficient than rebuilding the cluster and avoids granting the application container itself elevated privileges.

Exam trap

AI-200 often tests the confusion between container-level privilege (running as root) and node-level privilege (privileged container with CAP_SYS_MODULE), leading candidates to pick 'run as root' as a shortcut.

How to eliminate wrong answers

Option A is wrong because mounting /proc read-write does not grant the capability to load kernel modules — module loading requires CAP_SYS_MODULE and privileged access, not just filesystem permissions. Option B is wrong because running the application as root does not by itself allow kernel module insertion; root inside a container is still constrained by namespaces and dropped capabilities unless the container is privileged. Option D is wrong because rebuilding the AKS cluster is a drastic, slow operation that does not address ongoing driver management and would need to be repeated for every driver update.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid autoscaling options for AKS?

Select 2 answers

A.Cluster Autoscaler (CA).

B.Manual registry scaling.

C.Horizontal Pod Autoscaler (HPA).

D.Storage capacity scaling.

E.Azure Service Bus scaling.

AnswersA, C

Cluster Autoscaler adjusts the number of nodes in the AKS node pool when pods cannot be scheduled due to insufficient resources, scaling infrastructure rather than replicas. It is a native AKS autoscaling option, satisfying the question's requirement for valid autoscaling options.

Why this answer

Option A, Cluster Autoscaler (CA), is correct because it is a built-in AKS feature that automatically adjusts the number of nodes in a node pool based on pending pod resource requests and node utilization, scaling the cluster infrastructure up or down within configured min/max bounds. Option C, Horizontal Pod Autoscaler (HPA), is correct because it is a native Kubernetes autoscaling mechanism supported in AKS that scales the number of pod replicas in a Deployment, ReplicaSet, or StatefulSet based on observed metrics such as CPU, memory, or custom metrics. The other options are not valid AKS autoscaling options: manual registry scaling (B) is not an autoscaling feature at all, storage capacity scaling (D) refers to resizing persistent volumes rather than automatically scaling compute workloads, and Azure Service Bus scaling (E) is a messaging service concern, not an AKS autoscaling mechanism.

Exam trap

AI-200 often tests the confusion between pod-level and node-level autoscaling — candidates mistakenly pick storage or messaging options that sound like scaling but are not AKS autoscaling primitives.

Practice this question →

MCQmedium

You need to deploy a real-time object detection model inside an Azure Container App. The application requires immediate scale-out when the queue length of incoming image processing requests exceeds a threshold. Which scaling rule type should you configure?

A.Azure Queue Storage / Service Bus KEDA scaling rule

B.Memory utilization scaling rule

C.CPU utilization scaling rule

D.HTTP concurrency scaling rule

AnswerA

A KEDA queue scaler polls Azure Queue Storage or Service Bus and drives replica count from message backlog, so scale-out triggers the moment queue length crosses your threshold. This satisfies the stem's demand for immediate, event-driven scaling of the containerised object detection workload, unlike CPU or HTTP-based rules that lag behind queue depth.

Why this answer

Azure Container Apps uses KEDA (Kubernetes Event-Driven Autoscaling) scalers to scale based on external event sources. A queue-length trigger from Azure Queue Storage or Service Bus is the correct KEDA scaler when the workload must scale out in response to the number of pending messages, which matches the requirement of scaling when image processing requests exceed a threshold.

Exam trap

The trap here is that candidates often pick CPU or memory scalers because they assume resource pressure equals demand, but AI-200 tests the distinction between event-driven (KEDA) and resource-driven scaling for asynchronous workloads.

How to eliminate wrong answers

Option B is wrong because memory utilization is a resource-based metric that reacts to consumption inside the container, not to the arrival rate of queued requests, so it cannot provide immediate scale-out on queue depth. Option C is wrong for the same reason — CPU utilization lags behind the actual queue buildup and may not trigger until the container is already saturated. Option D is wrong because HTTP concurrency scales on simultaneous inbound HTTP connections, which is useful for synchronous APIs but does not reflect the backlog of asynchronous image processing requests sitting in a queue.

Practice this question →

MCQmedium

You are troubleshooting a containerized AI model running in an Azure Container App that crashes immediately upon startup with an exit code indicating an Out Of Memory (OOM) error. You need to inspect the container resource allocations. Where can you adjust the memory allocation for the container?

A.In the Azure Container Registry webhook configuration

B.In the Azure Container App revision template settings under container resource allocation

C.In the Azure Virtual Network route table settings

D.In the Azure Monitor diagnostic settings export destination

AnswerB

Memory and CPU limits are configured per container in the revision template's container resource allocation section. Raising the memory limit there resolves the OOM exit, directly satisfying the stem's requirement to inspect and adjust container resource allocations.

Why this answer

Azure Container Apps defines resource allocations (CPU cores and memory) per container inside the revision template. To fix an OOM crash, you edit the container's resources.requests (or the equivalent cpu/memory fields) in the revision template, which creates a new revision with the increased memory limit.

Exam trap

AI-200 often tests the misconception that resource limits can be adjusted via monitoring or networking settings, when they are strictly defined in the Container App revision template.

How to eliminate wrong answers

Option A is wrong because ACR webhooks trigger actions on image push/pull events and have no relationship to container runtime resource limits. Option C is wrong because VNet route tables control network traffic routing (UDRs) and cannot influence container memory allocation. Option D is wrong because Azure Monitor diagnostic settings control where telemetry (logs, metrics) is exported — they observe resource usage but do not configure it.

Practice this question →

MCQmedium

You are configuring continuous deployment for an AI model container using Azure DevOps and Azure Container Registry (ACR). You need to ensure that when a new container image is pushed to ACR, an event triggers an automated webhook that notifies an Azure Function to run post-deployment validation tests. Which event type should you subscribe to in the ACR webhook configuration?

A.artifactDelete

B.chartPush

C.imagePush

D.quarantineStatusChange

AnswerC

imagePush fires whenever a new image or tag lands in the registry, matching the requirement for a push-triggered webhook. Other event types such as imageDelete or chartPush do not cover image publication, so subscribing to imagePush lets the Azure Function run validation immediately after deployment.

Why this answer

The imagePush event fires whenever a new container image or tag is pushed to the registry, which is exactly the trigger needed to invoke a webhook that notifies an Azure Function for post-deployment validation. ACR webhooks subscribe to specific event types, and imagePush is the canonical event for CI/CD pipelines reacting to new images.

Exam trap

AI-200 often tests whether candidates can distinguish ACR event types — imagePush is the obvious answer, but chartPush and quarantineStatusChange are plausible-sounding distractors that only apply to Helm charts or content-trust workflows.

How to eliminate wrong answers

Option A is wrong because artifactDelete fires when an artifact (image manifest or tag) is deleted, which is a cleanup event, not a deployment trigger. Option B is wrong because chartPush fires only for Helm chart pushes to an OCI-compliant registry, not for container image pushes. Option D is wrong because quarantineStatusChange fires when an image's quarantine status changes (used with content trust/Notary), which is unrelated to triggering deployment validation.

Practice this question →

Multi-Selecteasy

Which THREE of the following are common reasons for a container image pull failure in AKS?

Select 3 answers

A.The node has too much memory.

B.Network connectivity issues to ACR.

C.Insufficient permissions (missing pull secrets).

D.The container is running too fast.

E.Invalid image tag or registry path.

AnswersB, C, E

Network connectivity issues to ACR directly satisfy the stem's requirement for a common pull failure cause. When the kubelet on a node cannot reach the registry endpoint, image layers never download, producing ImagePullBackOff. This occurs with misconfigured network policies, private endpoints, or DNS resolution failures blocking access to the container registry.

Why this answer

Option B is correct because AKS nodes must reach the registry endpoint (for example, myregistry.azurecr.io over HTTPS/443), and blocked egress, NSG/UDR misconfiguration, private endpoint or DNS resolution problems will cause the kubelet to fail the image pull. Option C is correct because pulling from a private registry such as ACR requires valid credentials — either an imagePullSecret, the AKS-managed AcrPull role assignment, or kubelet identity — and missing or expired permissions produce an authentication failure. Option E is correct because an invalid image tag or registry path (for example, a nonexistent tag or a misspelled registry/repository) makes the image unresolvable, yielding a manifest unknown or not found error.

Option A is not a pull failure cause: excessive node memory does not prevent image retrieval, and insufficient memory would instead cause scheduling or OOM issues. Option D is not relevant: how fast a container runs has no bearing on whether its image can be pulled from a registry.

Exam trap

AI-200 often tests distractors that sound plausible but are unrelated to image pulls (memory, runtime speed) — candidates must recognize that pull failures are strictly about network, auth, or image reference correctness.

Practice this question →

MCQhard

You are containerizing a large language model (LLM) inference API to run in Azure Container Apps. The model weights exceed 15 GB and cause container startup timeouts because the image takes too long to pull from Azure Container Registry (ACR). You need to optimize the container startup performance without reducing the model size. What is the best approach?

A.Upgrade the Azure Container Apps environment to use HTTP/2 protocol.

B.Store the model weights in an Azure Blob Storage account and mount them via an ephemeral volume.

C.Configure ACR content trust and geo-replication.

D.Enable ACR artifact streaming for the container registry.

AnswerD

ACR artifact streaming lets Azure Container Apps pull individual image layers on demand rather than downloading the full 15 GB image first, cutting startup latency. The model size stays unchanged, satisfying the constraint that weights must not be reduced.

Why this answer

ACR artifact streaming lets ACR stream image layers directly to the container runtime on demand rather than requiring the full image to be pulled and extracted before startup. This dramatically reduces cold-start time for large images like LLM weight layers, without shrinking the model. It is the purpose-built ACR feature for exactly this startup-latency problem.

Exam trap

AI-200 often tests the confusion between image optimization techniques — candidates pick geo-replication or content trust thinking they speed up pulls, when only artifact streaming addresses large-layer startup latency.

How to eliminate wrong answers

Option A is wrong because HTTP/2 affects transport efficiency for API calls but does not change how image layers are pulled from ACR — it does not address the 15 GB pull bottleneck. Option B is wrong because mounting model weights from Blob Storage via an ephemeral volume still requires downloading the weights at container start, and it adds complexity (mount latency, SDK changes) without solving the fundamental pull-time problem; it also does not reduce the image pull itself. Option C is wrong because content trust (image signing) and geo-replication improve integrity and regional availability, not startup performance — geo-replication can reduce pull latency if the replica is closer, but it does not address the core large-layer streaming problem the way artifact streaming does.

Practice this question →

MCQeasy

Your development team wants to push custom Docker images containing fine-tuned open-source LLMs to a secure, private registry hosted on Azure. Which Azure service should you use to store and manage these container images?

A.Azure Files

B.Azure Artifacts

C.Azure Blob Storage

D.Azure Container Registry

AnswerD

Azure Container Registry is a private, managed Docker registry supporting authentication, RBAC and geo-replication, satisfying the secure private storage requirement for custom fine-tuned LLM images. It stores and manages OCI artefacts natively, unlike general blob storage or public registries.

Why this answer

Azure Container Registry (ACR) is Azure's managed, private Docker registry service, purpose-built to store, version, and distribute OCI-compliant container images and Helm charts. It supports geo-replication, private endpoints, content trust, and integration with AKS, Container Apps, and ACI, making it the correct choice for hosting fine-tuned LLM container images securely. Blob Storage and Azure Files can hold bytes but lack the Docker Registry HTTP API v2 needed for image push/pull.

Exam trap

AI-200 often tests whether candidates confuse generic storage (Blob, Files) with a true container registry, so the trap is picking Blob Storage because ACR 'uses blobs underneath' — but only ACR exposes the registry API.

How to eliminate wrong answers

Option A is wrong because Azure Files is an SMB/NFS file share service for general-purpose file data, not a container registry — it cannot serve Docker Registry API v2 requests. Option B is wrong because Azure Artifacts is a package feed for NuGet, npm, Maven, Python, and similar package types, not for OCI container images. Option C is wrong because Azure Blob Storage is object storage; while ACR internally uses blob storage as its backing store, you cannot push or pull Docker images directly against a blob container without the registry layer.

Practice this question →

MCQeasy

You need to deploy a microservice application that consists of an API gateway and an AI model inference container. The solution must scale automatically based on HTTP traffic and support zero scaling when idle to reduce costs, without requiring complex Kubernetes cluster management. Which service is best suited for this?

A.Azure App Service for Containers

B.Azure Batch

C.Azure Container Apps

D.Azure Kubernetes Service (AKS)

AnswerC

Azure Container Apps provides HTTP-based KEDA scaling, including scale-to-zero when idle, and runs containers without exposing Kubernetes control-plane management. This satisfies both the automatic HTTP traffic scaling and zero-scaling cost requirements, whereas AKS demands cluster administration and Container Instances lack built-in autoscaling.

Why this answer

Azure Container Apps is a serverless container platform built on Kubernetes and KEDA that supports HTTP-based autoscaling, including scale-to-zero when idle. It abstracts away cluster management, making it ideal for microservices with an API gateway and an AI inference container that must scale on demand without operational overhead.

Exam trap

AI-200 often tests the distinction between scale-to-zero serverless containers (Container Apps) and always-on platforms (App Service) or self-managed orchestrators (AKS), with candidates overestimating App Service scaling capabilities.

How to eliminate wrong answers

Option A is wrong because Azure App Service for Containers does not support true scale-to-zero; it requires at least one running instance and has different scaling characteristics. Option B is wrong because Azure Batch is designed for large-scale parallel batch computing jobs, not for HTTP-triggered microservices with zero scaling. Option D is wrong because AKS requires managing Kubernetes clusters, nodes, and upgrades, which violates the 'without complex Kubernetes cluster management' requirement.

Practice this question →

Multi-Selecthard

Which THREE of the following items should be configured to ensure your AI workload in AKS is observable?

Select 3 answers

A.Prometheus and Grafana.

B.Integration with Application Insights.

C.Azure Backup.

D.Azure Monitor for Containers.

E.Azure Bastion.

AnswersA, B, D

Prometheus scrapes and stores time-series metrics from AKS nodes and pods, while Grafana renders those metrics as dashboards and alerts. Together they satisfy the observability requirement by exposing workload telemetry that Azure Monitor alone may not surface at the granularity AI training jobs demand.

Why this answer

Prometheus and Grafana (A) are correct because they provide the standard open-source metrics collection and dashboarding stack for Kubernetes, scraping AKS node, pod, and container metrics via exporters and kube-state-metrics to visualize workload health and performance. Integration with Application Insights (B) is correct because it enables distributed tracing, request/dependency telemetry, and live metrics for the AI application code running in AKS, which is essential for observing model inference latency and failures. Azure Monitor for Containers (D) is correct because it is the native AKS monitoring solution that collects container logs, node and pod metrics, and events into Log Analytics, providing out-of-the-box insights and alerts for the cluster.

Azure Backup (C) is incorrect because it is a data protection and disaster recovery service, not an observability tool, and Azure Bastion (E) is incorrect because it provides secure RDP/SSH access to VMs without exposing public IPs, which is unrelated to monitoring or telemetry.

Exam trap

AI-200 often tests whether candidates can distinguish observability tooling (metrics, logs, traces) from operational tooling (backup, bastion), and multi-select questions punish including unrelated services.

Practice this question →

MCQhard

You are configuring authentication between an Azure Container App running an AI model and an Azure OpenAI resource. To adhere to security best practices, you must avoid storing API keys in environment variables or code. How should you configure this?

A.Hardcode the secondary endpoint key into the Docker image build arguments

B.Enable anonymous public access on the Azure OpenAI resource for internal virtual network traffic

C.Configure a system-assigned managed identity on the Container App and grant it Cognitive Services OpenAI User role on the Azure OpenAI resource

D.Store the Azure OpenAI primary key in an Azure Key Vault and reference it via Container App secrets with plain text retrieval

AnswerC

A system-assigned managed identity lets the Container App obtain Microsoft Entra ID tokens for Azure OpenAI, with the Cognitive Services OpenAI User role granting access. No API keys are stored in code or environment variables, satisfying the security constraint.

Why this answer

A system-assigned managed identity on the Container App gives it an identity in Microsoft Entra ID, and granting that identity the Cognitive Services OpenAI User role on the Azure OpenAI resource authorizes token-based access without any stored secret. The Container App SDK/Managed Identity endpoint issues short-lived tokens automatically, eliminating keys in code or environment variables. This is the recommended keyless authentication pattern for Azure-to-Azure service calls.

Exam trap

The trap is treating Key Vault storage as equivalent to keyless auth; the exam wants managed identity plus RBAC, not secret retrieval, because the requirement is to avoid storing keys at all.

How to eliminate wrong answers

Option A is wrong because hardcoding a key into build arguments embeds the secret in image layers and build history, which is exactly the anti-pattern the question forbids. Option B is wrong because enabling anonymous public access removes authentication entirely and exposes the model to anyone who can reach the endpoint, violating least privilege. Option D is wrong because although Key Vault is better than hardcoding, retrieving the key as plain text into Container App secrets still materializes a long-lived secret in the app environment rather than using identity-based auth.

Practice this question →

MCQeasy

You need to deploy a quick, stateless AI data processing script packaged in a container image without setting up Kubernetes or Container Apps. Which Azure service offers the fastest deployment for a single container instance?

A.Azure Virtual Machines with Docker installed

B.Azure Container Instances

C.Azure App Service for Linux

D.Azure Kubernetes Service

AnswerB

Azure Container Instances runs a single container image directly with no cluster orchestration or environment scaffolding, billing per second of execution. This satisfies the stateless, fastest-deployment constraint by avoiding Kubernetes and Container Apps provisioning overhead entirely.

Why this answer

Azure Container Instances (ACI) is a serverless container runtime that deploys a single container (or container group) in seconds via a single CLI command or ARM template, with no cluster or orchestrator to provision. It bills per-second for vCPU and memory consumed, making it ideal for short-lived, stateless AI data processing jobs. Because there is no node pool, ingress controller, or control plane to manage, ACI delivers the fastest path from image to running container.

Exam trap

AI-200 often tests the distinction between 'fastest/simplest single-container deployment' (ACI) and 'orchestrated, scalable container platform' (AKS or Container Apps), so candidates over-engineer by choosing AKS when the scenario explicitly says no Kubernetes.

How to eliminate wrong answers

Option A is wrong because Azure Virtual Machines require you to provision the VM, install and patch Docker, configure networking and OS updates, and manage the host lifecycle — far slower than a serverless container service. Option C is wrong because Azure App Service for Linux is a PaaS web-hosting platform optimized for long-running web apps and APIs, not for quick one-off stateless container jobs, and it requires an App Service Plan with ongoing cost. Option D is wrong because Azure Kubernetes Service provisions a full managed Kubernetes control plane plus node pools, which takes minutes and adds orchestration overhead that is unnecessary for a single container instance.

Practice this question →

Multi-Selecteasy

Which TWO actions can you perform using Azure Container Registry Tasks (ACR Tasks)?

Select 2 answers

A.Manage Azure Virtual Machine backups

B.Automate image builds upon Git source code repository commits

C.Build container images in the cloud without needing a local Docker daemon

D.Configure Azure Front Door routing rules

E.Deploy AKS clusters automatically

AnswersB, C

ACR Tasks supports automated builds triggered by source code commits to a Git repository, using quick tasks or multi-step task definitions. This satisfies the stem's automation requirement by rebuilding container images whenever code changes, removing manual intervention and enabling continuous integration directly within Azure Container Registry.

Why this answer

Option B is correct because ACR Tasks supports multi-step and single-step tasks that can be triggered automatically by source code commits to a Git repository (via the source trigger feature), enabling continuous integration image builds. Option C is correct because ACR Tasks performs builds in the Azure cloud using the ACR build infrastructure, so no local Docker daemon or Docker CLI is required on the developer's machine. Option A is incorrect because Azure Virtual Machine backups are handled by Azure Backup and Recovery Services vaults, not ACR Tasks.

Option D is incorrect because Azure Front Door routing rules are configured through Azure Front Door, a content delivery and global load-balancing service, unrelated to container image builds. Option E is incorrect because AKS cluster deployment is performed via the Azure portal, CLI, ARM/Bicep templates, or Terraform, not through ACR Tasks, which only builds and manages container images.

Exam trap

AI-200 often tests whether candidates confuse ACR Tasks (image build automation) with broader Azure services like AKS, Azure Backup, or Front Door, so any option mentioning cluster deployment or networking is a distractor.

Practice this question →

MCQhard

An AKS cluster is configured with KEDA for autoscaling an AI inferencing service based on Azure Queue Storage length. The pods fail to scale. Which component should you inspect first?

A.The Azure Container Registry webhook settings.

B.The Horizontal Pod Autoscaler (HPA) resource directly.

C.The Cluster Autoscaler logs.

D.The ScaledObject resource status.

AnswerD

KEDA's ScaledObject holds the trigger configuration, polling interval and scaling status; a misconfigured or erroring ScaledObject prevents scaling entirely. Inspecting its status and events reveals authentication or queue-metric failures before checking the HPA or deployment.

Why this answer

KEDA works by creating and managing a Horizontal Pod Autoscaler behind the scenes, but the user-facing configuration object is the ScaledObject, which defines the trigger (Azure Queue Storage), min/max replicas, and target workload. If scaling fails, the ScaledObject's status conditions and events reveal authentication errors, trigger misconfiguration, or missing metadata. Inspecting it first is the fastest path to the root cause.

Exam trap

AI-200 often tests whether candidates know that KEDA creates the HPA automatically, so troubleshooting should start at the ScaledObject (the source of truth) rather than the HPA (the derived resource).

How to eliminate wrong answers

Option A is wrong because Azure Container Registry webhooks notify on image push/pull events and have no role in KEDA autoscaling decisions. Option B is wrong because the HPA is a downstream artifact created by KEDA; inspecting it directly shows symptoms (e.g., unknown metric) but not the trigger-level cause, and KEDA may not have created it if the ScaledObject is invalid. Option C is wrong because the Cluster Autoscaler adds or removes nodes when pods are unschedulable — it is a node-level concern, not the pod-replica scaling driven by KEDA.

Practice this question →

MCQhard

You are deploying a custom AI model container to Azure Container Apps. The container listens on port 8080 and requires health probes to verify readiness before routing traffic. How should you configure the probes?

A.Configure an Azure Front Door health probe pointing to the internal container IP

B.Configure a TCP liveness probe pointing to port 22 for SSH management

C.Configure an HTTP readiness probe targeting port 8080 on your health check endpoint

D.Configure a startup probe that restarts the container if CPU usage drops below 5 percent

AnswerC

An HTTP readiness probe on port 8080 matches the container's listening port and verifies application-level readiness before Azure Container Apps routes traffic. HTTP probes validate a specific health endpoint returning success, unlike TCP probes which only confirm the port is open, so they satisfy the stem's requirement to verify readiness accurately.

Why this answer

Azure Container Apps supports HTTP and TCP probes defined at the container level, and an HTTP readiness probe is the correct mechanism to signal that the app is ready to receive traffic on its listening port. Since the container listens on port 8080 and exposes a health check endpoint, an HTTP readiness probe targeting that port lets the platform delay traffic routing until the endpoint returns a success status code. This matches the Kubernetes-style probe model that Container Apps implements, where readiness probes control traffic admission rather than process restart.

Exam trap

AI-200 often tests whether candidates confuse the three probe types — picking a liveness probe when readiness is required, or assuming probes can be defined at the ingress/Front Door layer instead of on the container itself.

How to eliminate wrong answers

Option A is wrong because Azure Front Door health probes operate at the edge/ingress layer against a public or private endpoint, not against an internal container IP inside the Container Apps environment, and Front Door is not the component that gates revision traffic routing. Option B is wrong because port 22 is SSH, not the application's listening port, and a TCP liveness probe against SSH would only verify that the SSH daemon is accepting connections — it says nothing about whether the AI model HTTP service on 8080 is ready. Option D is wrong because startup probes in Container Apps are HTTP or TCP checks against the container, not CPU-threshold monitors, and restarting on low CPU is a nonsensical readiness signal that would cause flapping.

Practice this question →

MCQeasy

You want to view real-time standard output logs from a container running in Azure Container Instances named 'ai-inferencing-aci'. Which Azure CLI command should you run?

A.az container show --resource-group myRG --name ai-inferencing-aci

B.az aks browse --name ai-inferencing-aci

C.az container logs --resource-group myRG --name ai-inferencing-aci

D.az acr repository show-tags

AnswerC

The az container logs command streams a container group's stdout, and --name identifies the container group while --resource-group scopes it. This returns the real-time standard output for ai-inferencing-aci, which az container show or attach would not provide.

Why this answer

The 'az container logs' command retrieves the stdout/stderr logs from a container running in Azure Container Instances, which is exactly what is needed to view real-time standard output. It accepts --resource-group and --name to identify the container group and supports --follow to stream logs continuously. This is the canonical CLI command for ACI log inspection.

Exam trap

AI-200 often tests whether candidates confuse 'az container show' (metadata/state) with 'az container logs' (runtime output), or mix up ACI commands with AKS commands like 'az aks browse'.

How to eliminate wrong answers

Option A is wrong because 'az container show' returns the container group's metadata and provisioning state (JSON properties), not its runtime logs. Option B is wrong because 'az aks browse' opens the Kubernetes dashboard for an AKS cluster and is unrelated to ACI; the resource is a container instance, not an AKS cluster. Option D is wrong because 'az acr repository show-tags' lists tags in an Azure Container Registry repository — it inspects image metadata, not running container output.

Practice this question →

MCQhard

You deploy an AI inferencing service to an Azure Kubernetes Service (AKS) cluster. The service uses an ONNX Runtime container. Users report intermittent 504 Gateway Timeouts during peak batch request loads. You notice that the application pods are being terminated due to Out-Of-Memory (OOM) errors during heavy inference loads. How should you resolve this issue in your Kubernetes deployment manifest?

A.Decrease the readiness probe failureThreshold to remove faulty pods faster.

B.Increase the memory limit value in the container resource specifications.

C.Enable the Kubernetes Horizontal Pod Autoscaler based on CPU utilization.

D.Configure a liveness probe with an increased initialDelaySeconds value.

AnswerB

OOM kills stem from the container exceeding its memory limit during heavy inference, so raising the memory limit value in the resource specifications gives pods headroom to complete batch requests without termination, addressing the root cause rather than the resulting 504 timeouts.

Why this answer

The pods are being OOM-killed because the container's memory limit is lower than the peak memory required during heavy inference. Increasing the memory limit in the container resource specifications gives the ONNX Runtime process enough headroom to complete batch inference without being terminated by the kernel OOM killer. This directly addresses the root cause of the 504 timeouts, which occur because pods die mid-request.

Exam trap

AI-200 often tests the distinction between scaling out (HPA) and scaling up (resource limits), tricking candidates into choosing HPA when the actual symptom is per-pod OOM termination.

How to eliminate wrong answers

Option A is wrong because decreasing the readiness probe failureThreshold only affects how quickly a pod is marked unready; it does not prevent OOM kills and could even remove pods faster without fixing the underlying memory shortage. Option C is wrong because HPA based on CPU scales out replicas but does not increase per-pod memory; if each pod still OOMs under load, adding more pods may not help and could worsen node-level memory pressure. Option D is wrong because increasing initialDelaySeconds on a liveness probe only delays the first probe; it does not address OOM termination, which is enforced by the kernel, not the probe.

Practice this question →

MCQeasy

You need to view the logs of a container that recently crashed in an AKS cluster. Which command is used?

A.kubectl get pods.

B.az aks logs.

C.kubectl describe pod.

D.kubectl logs <pod-name> --previous.

AnswerD

The --previous flag retrieves logs from the terminated instance of the container, which is essential after a crash because the current pod may have restarted. Plain kubectl logs shows only the running container, so --previous satisfies the need to inspect the crashed instance's output.

Why this answer

The `kubectl logs <pod-name> --previous` command retrieves the logs from the previous (crashed) container instance in a pod. When a container crashes and restarts, the current container's logs may be empty or show only the new startup, so the `--previous` flag is essential to access the terminated container's output. This is the standard kubectl mechanism for post-mortem debugging of crashed containers in AKS.

Exam trap

AI-200 often tests the distinction between `kubectl describe pod` (events and state) and `kubectl logs --previous` (actual crash output), tricking candidates who assume describe shows logs.

How to eliminate wrong answers

Option A is wrong because `kubectl get pods` only lists pods and their status/restart counts — it does not retrieve any log output. Option B is wrong because `az aks logs` is not a valid Azure CLI command; AKS log retrieval is done via kubectl or Azure Monitor/Container Insights, not a direct `az aks logs` subcommand. Option C is wrong because `kubectl describe pod` shows events, status conditions, and container state (including last termination reason) but not the actual stdout/stderr log content of the crashed container.

Practice this question →

MCQhard

You are deploying a model that requires a specific version of a non-standard OS library. You want to ensure the build environment is consistent across your team. What should you use?

A.Manual installation on the build agent.

B.A Dockerfile with fixed base image tags.

C.Install the library via a post-deployment script.

D.Use the 'latest' tag for the base image.

AnswerB

A Dockerfile with pinned base image tags locks the OS layer and library versions, so every teammate builds against the identical environment. This directly satisfies the stem's requirement for a consistent build environment when a specific non-standard OS library version is needed, rather than relying on mutable tags or host configuration.

Why this answer

A Dockerfile with pinned base image tags (e.g., python:3.11.7-slim rather than python:latest) guarantees that every team member and CI run builds against the exact same OS libraries and toolchain. This reproducibility is the core requirement for consistent build environments.

Exam trap

AI-200 often tests the misconception that 'latest' is a stable, reproducible tag — candidates pick it thinking it always gives the newest, most consistent environment, when it actually introduces drift.

How to eliminate wrong answers

Option A is wrong because manual installation on the build agent is not reproducible — different agents drift, and the environment cannot be version-controlled or shared. Option C is wrong because a post-deployment script runs after the artifact is built, so it cannot guarantee the build environment itself is consistent and may fail at runtime. Option D is wrong because the 'latest' tag is mutable and can silently pull a newer base image, breaking reproducibility and introducing unexpected library changes.

Practice this question →

MCQeasy

You are deploying a web application container to Azure Container Apps and want to enable external HTTPS traffic. Which ingress setting must you configure?

A.Set target port to 80 and protocol to TCP

B.Enable ingress with external traffic permitted

C.Disable ingress entirely

D.Configure internal ingress only

AnswerB

Ingress must be enabled with external traffic permitted so the container app receives a publicly resolvable FQDN and terminates HTTPS at the platform's ingress controller. Internal-only ingress would restrict access to the Container Apps environment, failing the stem's external HTTPS requirement.

Why this answer

To expose a Container App to the public internet over HTTPS, you must enable ingress and set it to accept external traffic. Container Apps then provisions a fully qualified domain name (FQDN) and a managed TLS certificate automatically, terminating HTTPS at the ingress layer. Without external ingress enabled, the app is only reachable inside the environment.

Exam trap

The trap is thinking that setting a port or protocol is sufficient for external HTTPS; candidates must remember that ingress must be explicitly enabled and set to external to get a public FQDN and managed TLS.

How to eliminate wrong answers

Option A is wrong because setting target port 80 and protocol TCP alone does not enable ingress or external exposure — ingress must be enabled and set to external. Option C is wrong because disabling ingress makes the app unreachable from any network, including the internet. Option D is wrong because internal ingress only exposes the app within the Container Apps environment or VNet, not to the public internet.

Practice this question →

MCQmedium

You want to ensure your AI inference service is highly available across multiple regions. What is the recommended approach for container distribution?

A.Store images in a public Docker Hub account.

B.Use a single global ACR endpoint.

C.Manually copy images using a script.

D.Enable ACR Georeplication.

AnswerD

ACR georeplication maintains registry replicas in each chosen Azure region, so container pulls resolve locally rather than crossing regions. This directly satisfies the multi-region availability constraint: if one region fails, inference nodes still pull images from their nearest healthy replica, avoiding a single-region registry as a failure point.

Why this answer

ACR geo-replication lets a single registry definition replicate images to multiple Azure regions automatically, so each regional inference endpoint pulls from a local replica with low latency and survives a regional outage. It also supports regional failover without manual image copying.

Exam trap

AI-200 often tests whether candidates confuse 'global endpoint' with geo-replication — ACR has no single global endpoint; geo-replication is the actual HA mechanism.

How to eliminate wrong answers

Option A is wrong because Docker Hub is a public third-party registry with rate limits, no SLA, and no private-network integration — unsuitable for production AI inference. Option B is wrong because ACR does not offer a single 'global endpoint' that magically serves all regions; without geo-replication, pulls cross regions and add latency. Option C is wrong because manual copy scripts are error-prone, slow, and create drift between regions — the opposite of a managed HA pattern.

Practice this question →

Multi-Selecteasy

Which TWO of the following are true about Azure Container Apps?

Select 2 answers

A.You must manage the underlying Kubernetes nodes.

B.It is a serverless container platform.

C.It is not compatible with Dapr.

D.It supports KEDA for event-driven scaling.

E.It does not support VNETs.

AnswersB, D

Azure Container Apps abstracts the underlying Kubernetes infrastructure, scaling to zero when there is no traffic and charging only for consumed resources. This serverless execution model satisfies the stem's requirement by removing cluster management overhead, letting teams deploy containerised workloads without provisioning or paying for idle nodes.

Why this answer

Azure Container Apps is a fully managed, serverless container platform, so option B is correct: it abstracts away the Kubernetes control plane and nodes, letting you run containers without provisioning or managing infrastructure. Option D is also correct because Azure Container Apps uses KEDA (Kubernetes Event-driven Autoscaling) under the hood to scale containers based on events such as queues, HTTP traffic, or custom metrics. Option A is wrong because node management is handled by the platform, not the user.

Option C is wrong because Azure Container Apps has built-in Dapr integration for microservice building blocks. Option E is wrong because Azure Container Apps supports virtual network (VNET) integration for inbound and outbound connectivity.

Exam trap

AI-200 often tests the boundary between AKS (you manage nodes) and Container Apps (serverless, no node access), and candidates incorrectly assume Container Apps lacks enterprise networking or Dapr support.

Practice this question →

Multi-Selecteasy

When configuring an Azure Container Instances container group, which TWO properties can you define?

Select 2 answers

A.AKS node pool sizing

B.DNS name label for public IP resolution

C.Virtual machine scale set autoscaling rules

D.Kubernetes namespace allocation

E.Environment variables passed to the container runtime

AnswersB, E

Assigning a DNS name label gives the group's public IP a resolvable fully qualified domain name, enabling external clients to reach exposed ports. This is a definable container group property, satisfying the stem's requirement for configurable group settings.

Why this answer

Option B is correct because an Azure Container Instances container group can be exposed with a public IP address that includes a DNS name label, allowing resolution via <dns-name-label>.<region>.azurecontainer.io. Option E is correct because container groups support defining environment variables (including secure values) that are passed to the container runtime at startup, which is a core configuration property of ACI containers. Options A and C are incorrect because AKS node pool sizing and VM scale set autoscaling rules belong to AKS and Virtual Machine Scale Sets respectively, not to ACI container group configuration.

Option D is incorrect because Kubernetes namespace allocation is a Kubernetes/AKS concept and is not a property you define when configuring an ACI container group.

Exam trap

AI-200 often tests ACI vs AKS boundaries, so the trap is selecting Kubernetes/VMSS concepts (node pools, namespaces, autoscaling) that do not exist in ACI.

Practice this question →

MCQhard

You are configuring GPU time-slicing on an AKS cluster to maximize GPU utilization for multiple lightweight AI inference containers sharing a single NVIDIA A100 GPU. Where must you define the time-slicing configuration profile?

A.Inside the Dockerfile of each individual AI container

B.A Kubernetes ConfigMap referenced by the NVIDIA device plugin daemonset

C.Via Azure Container Apps workload profiles configuration

D.In the Azure portal under AKS cluster node pool properties

AnswerB

Time-slicing profiles are declared in a ConfigMap that the NVIDIA device plugin DaemonSet consumes, letting one A100 advertise multiple shared replicas to the scheduler. This satisfies the stem's requirement to maximise utilisation across lightweight inference containers, since the profile must exist before the plugin starts and cannot be set per pod.

Why this answer

A Kubernetes ConfigMap referenced by the NVIDIA device plugin daemonset is correct because GPU time-slicing on AKS is configured by creating a ConfigMap that contains the time-slicing profile (e.g., replicas: 4) and referencing it in the NVIDIA device plugin daemonset spec via a volume mount. The device plugin then advertises multiple virtual GPU resources per physical GPU, allowing multiple pods to share the A100.

Exam trap

AI-200 often tests the misconception that GPU sharing is configured in the container image or Azure portal, when in AKS it is always a Kubernetes ConfigMap consumed by the NVIDIA device plugin daemonset.

How to eliminate wrong answers

Option A is wrong because the Dockerfile builds the container image and has no visibility into GPU scheduling or the device plugin — time-slicing is a cluster-level GPU resource configuration, not an image-level setting. Option C is wrong because Azure Container Apps workload profiles are a different compute platform (serverless containers) and do not manage AKS GPU device plugin configuration; time-slicing is an AKS/NVIDIA device plugin concern. Option D is wrong because the Azure portal AKS node pool properties expose VM size and scaling settings but do not provide a UI for NVIDIA device plugin time-slicing profiles — this must be done via Kubernetes manifests (ConfigMap + daemonset patch).

Practice this question →

MCQhard

You are configuring network policies in an AKS cluster to isolate your AI inference pods from other namespaces. You notice that traffic is still flowing between namespaces despite applying a NetworkPolicy. What is the most likely cause?

A.The AKS cluster was deployed with a network plugin that does not enforce Kubernetes network policies

B.Network policies require IPv6 enablement on the cluster subnet

C.Network policies apply only to ingress controllers, not pod-to-pod traffic

D.Azure Firewall is blocking the network policy controller

AnswerA

AKS with the kubenet plugin does not enforce Kubernetes NetworkPolicy objects; only Azure CNI (or Calico) provides that enforcement. Since the stem describes policies being applied yet cross-namespace traffic still flowing, the cluster's network plugin is the cause — the policy exists but nothing implements it.

Why this answer

Kubernetes NetworkPolicy enforcement in AKS depends on the CNI/network plugin. The default 'kubenet' plugin and Azure CNI without a policy engine do not enforce NetworkPolicy objects — they are accepted by the API server but silently ignored. To enforce them you must use Azure CNI with Calico, Azure NPM (Network Policy Manager), or Cilium.

This is why traffic continues to flow between namespaces despite the policy being applied.

Exam trap

AI-200 often tests that NetworkPolicy objects are only enforced when the AKS cluster uses a compatible network plugin (Calico, Azure NPM, or Cilium), so candidates who assume 'applying the YAML is enough' pick a distractor about IPv6 or ingress controllers.

How to eliminate wrong answers

Option B is wrong because NetworkPolicy is an L3/L4 construct that works fine on IPv4; IPv6 enablement is unrelated to policy enforcement. Option C is wrong because NetworkPolicy explicitly governs pod-to-pod traffic (ingress and egress selectors), not just ingress controllers. Option D is wrong because Azure Firewall operates at the subnet/VNet egress layer and does not interfere with the in-cluster NetworkPolicy controller — it cannot 'block' policy enforcement.

Practice this question →

MCQeasy

Which type of registry is most suitable for storing images that are shared across an entire organization?

A.Docker Hub (Free).

B.GitHub Container Registry.

C.Local hard drive.

D.Azure Container Registry.

AnswerD

Azure Container Registry provides a private, organisation-scoped registry with Microsoft Entra ID authentication, role-based access control and geo-replication, letting teams across the organisation pull shared images. This satisfies the stem's requirement for organisation-wide image sharing.

Why this answer

Azure Container Registry (ACR) is the Azure-native private registry designed for organization-wide image sharing. It supports Azure RBAC, Microsoft Entra ID authentication, geo-replication, private endpoints, and integration with AKS, Container Apps, and ACI, making it the correct choice for enterprise-scale image distribution.

Exam trap

The trap here is assuming any container registry works for enterprise sharing; AI-200 expects you to recognize that only ACR provides Azure-native RBAC, private networking, and geo-replication required for organization-wide use.

How to eliminate wrong answers

Option A is wrong because Docker Hub Free is a public registry with rate limits, no enterprise RBAC, and no private networking, so it is unsuitable for organization-wide private image sharing. Option B is wrong because GitHub Container Registry is tied to GitHub identities and lacks the deep Azure RBAC, private endpoint, and geo-replication integration that enterprise Azure workloads require. Option C is wrong because a local hard drive is not a registry at all and cannot serve images to distributed compute.

Practice this question →

Multi-Selecteasy

Your team is evaluating Azure Container Apps versus Azure Kubernetes Service (AKS) for hosting containerized AI workloads. Which TWO characteristics are advantages of Azure Container Apps over standard AKS? (Choose two.)

Select 2 answers

A.Requirement to manage custom CNI overlay networking routing tables manually

B.Simplified container management without direct exposure or management of Kubernetes master nodes

C.Mandatory manual configuration of KEDA controllers and Ingress controllers

D.Built-in support for scaling automatically down to zero replicas when idle

E.Complete low-level administrative access to kernel modules and cluster root certificates

AnswersB, D

Azure Container Apps abstracts the Kubernetes control plane entirely, so teams deploy containers without provisioning, patching or paying for master nodes. This satisfies the stem's advantage criterion by removing cluster infrastructure management that standard AKS requires.

Why this answer

Option B is correct because Azure Container Apps is a serverless, fully managed container platform built on Kubernetes and KEDA, so the underlying Kubernetes control plane (master nodes) is abstracted away and never exposed to the customer for patching or management, unlike AKS where you are responsible for node pools and cluster operations. Option D is correct because Container Apps natively supports scale-to-zero via its built-in KEDA-based scaling rules, meaning idle workloads consume no compute and incur no cost, whereas standard AKS requires configuring cluster autoscaler or KEDA manually and typically keeps at least one node running. Option A is incorrect because Container Apps does not require you to manage CNI overlay routing tables; that is a low-level networking task associated with self-managed Kubernetes or advanced AKS CNI configurations.

Option C is incorrect because KEDA and ingress are built into Container Apps and configured declaratively, not mandatory manual controller installations. Option E is incorrect because Container Apps deliberately restricts low-level administrative access, including kernel modules and root certificates, which is the opposite of an advantage over AKS.

Exam trap

AI-200 often tests the misconception that Container Apps is 'AKS with a nicer UI' — candidates pick answers implying manual KEDA/ingress setup, which is exactly what Container Apps removes.

Practice this question →

Multi-Selectmedium

You are designing an MLOps pipeline on Azure Kubernetes Service (AKS) for a computer vision model. You need to configure GPU sharing among multiple inference pods on the same node to optimize cost. Which TWO actions should you take? Each correct answer presents part of the solution.

Select 2 answers

A.Set the pod priority class to system-node-critical.

B.Enable GPU time-slicing or NVIDIA Multi-Instance GPU (MIG) configuration.

C.Deploy the KEDA scaler with an Azure Queue trigger.

D.Configure the Azure CNI plugin for dynamic IP allocation.

E.Install the NVIDIA GPU Operator on the AKS cluster.

AnswersB, E

Time-slicing lets several pods share one physical GPU by interleaving execution, while MIG partitions the GPU into isolated instances with dedicated memory. Either mechanism satisfies the stem's requirement to share a single node's GPU across multiple inference pods and reduce cost.

Why this answer

Option B is correct because GPU sharing on AKS is achieved through NVIDIA's time-slicing or Multi-Instance GPU (MIG) configuration, which partitions a single physical GPU so multiple inference pods can run concurrently on the same node, directly reducing cost. Option E is correct because the NVIDIA GPU Operator automates the deployment and lifecycle of the GPU device plugin, drivers, container runtime, and related components on AKS, which is a prerequisite for enabling and managing time-slicing or MIG configurations. Option A is incorrect because a system-node-critical priority class only affects scheduling priority and eviction behavior; it does not enable GPU sharing.

Option C is incorrect because KEDA with an Azure Queue trigger provides event-driven autoscaling and has nothing to do with partitioning or sharing a GPU among pods. Option D is incorrect because Azure CNI dynamic IP allocation addresses pod IP address management and networking, not GPU resource sharing.

Exam trap

AI-200 often tests the misconception that autoscaling or networking features can enable GPU sharing, when in fact GPU sharing requires specific NVIDIA operator and device plugin configurations.

Practice this question →

Multi-Selectmedium

When managing Azure Container Registry (ACR), administrators can use ACR Tasks to automate tasks. Which TWO scenarios are valid use cases for ACR Tasks? (Choose two.)

Select 2 answers

A.Triggering container image rebuilds automatically when a base image is updated

B.Providing a managed Kubernetes API control plane

C.Executing automated container vulnerability scans directly inside registry storage

D.Running a persistent, multi-node enterprise database cluster inside ACR

E.Automatically building container images when code is committed to a GitHub repository

AnswersA, E

ACR Tasks supports base image update triggers, monitoring the registry for changes to a dependent base image and automatically rebuilding the derived image. This satisfies the stem's automation requirement, removing manual rebuild intervention when upstream base images change.

Why this answer

Option A is correct because ACR Tasks supports base image update triggers, which automatically rebuild dependent images when the base image in the same or another registry is updated, keeping images patched and current. Option E is correct because ACR Tasks provides source code triggers, including GitHub commit and pull request triggers, that automatically build and push container images when code changes are committed. Option B is incorrect because a managed Kubernetes API control plane is provided by Azure Kubernetes Service (AKS), not ACR.

Option C is incorrect because ACR Tasks builds and runs container workloads; vulnerability scanning is provided by Microsoft Defender for Containers or third-party integrations, not by executing scans inside registry storage. Option D is incorrect because ACR is a container image and artifact registry, not a platform for running persistent multi-node database clusters.

Exam trap

AI-200 often tests the confusion between ACR Tasks (build automation) and Defender for Containers (vulnerability scanning), causing candidates to pick scanning as an ACR Tasks use case.

Practice this question →

MCQeasy

You need to inspect the environment variables and configuration settings of a running container group in Azure Container Instances. Which Azure CLI command should you use?

A.az container exec --exec-command env

B.az aks inspect

C.az container list-secrets

D.az container show --resource-group myRG --name myContainer

AnswerD

az container show retrieves the full JSON properties of a container group, including environment variables and configuration settings, directly satisfying the inspection requirement. It queries the running group's current state rather than logs or metrics, which would not expose configuration values.

Why this answer

The az container show command retrieves the full JSON representation of a container group, including its container definitions, environment variables, image, ports, resource requests, and current provisioning state. This is the correct way to inspect configuration of a running container group without executing into it.

Exam trap

AI-200 often tests the confusion between inspecting configuration (az container show) and executing commands inside a container (az container exec), especially when the word 'environment variables' appears in both contexts.

How to eliminate wrong answers

Option A is wrong because az container exec runs a command inside the container — while 'env' would print environment variables at runtime, the question asks to inspect configuration settings of the container group, and exec requires the container to be running and is not the configuration-inspection command. Option B is wrong because az aks inspect is not a valid Azure CLI command (AKS diagnostics use az aks show, az aks get-credentials, or kubectl). Option C is wrong because az container list-secrets is not a valid command — secrets in ACI are surfaced via az container show output, not a dedicated list-secrets verb.

Practice this question →

MCQhard

You are configuring secure image signing and verification for your AI containers using Azure Container Registry and Notation. Which feature enables cryptographically signed container images?

A.ACR Signature Verification / Microsoft Defender artifact signing with Notation

B.Azure Key Vault managed HSM key rotation

C.ACR Georeplication sync tokens

D.Docker Content Trust (Notary v1)

AnswerA

ACR Signature Verification integrates Notation with Microsoft Entra ID–backed certificates, storing signatures as OCI artifacts alongside the image. This satisfies the stem's requirement for cryptographic signing and verification, since Notation uses COSE signatures validated against trusted certificate chains before deployment.

Why this answer

ACR Signature Verification, integrated with Microsoft Defender for Containers and Notation (the CNCF Notary v2 project), enables cryptographically signed container images and policy-based verification at pull time. Notation uses the OCI 1.1 referrers API to store signatures as artifacts alongside the image, and ACR can enforce that only signed images are pulled. This is the modern, standards-based approach for supply-chain integrity in Azure.

Exam trap

AI-200 often tests the shift from Docker Content Trust (Notary v1) to Notation (Notary v2) for ACR image signing, so candidates who pick the legacy DCT option get it wrong.

How to eliminate wrong answers

Option B is wrong because Key Vault managed HSM key rotation manages cryptographic keys but does not sign or verify container images. Option C is wrong because ACR georeplication sync tokens control replication across regions, not image signing. Option D is wrong because Docker Content Trust (Notary v1) is the legacy signing mechanism, deprecated in favor of Notation/Notary v2, and not the feature Microsoft positions for ACR signature verification.

Practice this question →

MCQeasy

You are deploying a containerized AI web API to Azure Container Apps. The API must be accessible from the public internet over HTTPS. You have already created the container app and deployed the image. Which of the following should you configure to enable external ingress with automatic HTTPS?

A.Set the ingress to 'external' and enable 'allowInsecure' to false in the container app configuration.

B.Deploy the container app to an internal environment and configure a private DNS zone for public resolution.

C.Enable HTTP/2 and set the transport to 'auto' in the ingress settings.

D.Create an Azure Application Gateway with a public IP and configure it to forward traffic to the container app's internal endpoint.

AnswerA

In Azure Container Apps, to expose a container app to the public internet, you configure ingress with 'external' set to true (or 'external' in CLI). By default, Container Apps provides automatic HTTPS with a fully managed certificate. Setting 'allowInsecure' to false ensures that only HTTPS traffic is allowed, redirecting HTTP to HTTPS. This meets the requirement for secure public access.

Why this answer

Azure Container Apps provides built-in ingress that can be configured as external to expose the app to the internet. When external ingress is enabled, Container Apps automatically provisions a fully managed TLS certificate and supports HTTPS. Setting 'allowInsecure' to false enforces HTTPS-only traffic.

Other options either add unnecessary components or do not provide public access.

Exam trap

The trap here is overcomplicating the solution by introducing additional services like Application Gateway, when Container Apps natively supports external ingress with automatic HTTPS.

Practice this question →

MCQmedium

You are managing multiple containerized AI models in AKS. You want to implement a service mesh to handle traffic splitting and mTLS. Which tool should you integrate?

A.Calico.

B.Azure Application Gateway Ingress Controller (AGIC).

C.Istio.

D.Azure Load Balancer.

AnswerC

Istio provides native traffic splitting through VirtualService weights and mutual TLS between pods, meeting both requirements without custom code. Its sidecar proxies enforce mTLS automatically, whereas alternatives such as Linkerd or ingress-only controllers lack the same combined traffic-shifting and mTLS feature set.

Why this answer

Istio is a full-featured service mesh that provides traffic splitting (via VirtualService and DestinationRule), mutual TLS (mTLS) between workloads, observability, and policy enforcement. It is the standard choice for AKS service mesh requirements, and AKS offers an Istio add-on for simplified installation and lifecycle management. This directly satisfies the traffic-splitting and mTLS requirements.

Exam trap

The trap is confusing ingress controllers (AGIC) or CNIs (Calico) with service meshes; only Istio provides the combination of traffic splitting and mTLS that the question requires.

How to eliminate wrong answers

Option A is wrong because Calico is a CNI and network policy engine, not a service mesh — it does not provide traffic splitting or mTLS. Option B is wrong because AGIC is an ingress controller that routes external HTTP(S) traffic into the cluster; it does not provide east-west mTLS or fine-grained traffic splitting between services. Option D is wrong because Azure Load Balancer is an L4 load balancer that distributes TCP/UDP traffic but has no concept of service mesh, mTLS, or HTTP-level traffic splitting.

Practice this question →

MCQmedium

Your containerized AI application needs to access sensitive API keys. What is the most secure way to provide these to your application in Azure Container Apps?

A.Store them in environment variables in the YAML file.

B.Hardcode them in the application code.

C.Store them in a sidecar container.

D.Use Azure Key Vault references.

AnswerD

Key Vault references let Container Apps resolve secrets at runtime through the app's managed identity, so API keys never enter the container image, environment variables, or revision configuration. This satisfies the sensitive-credential requirement by removing plaintext secrets from the deployment entirely.

Why this answer

Azure Key Vault references let Container Apps pull secrets at runtime from Key Vault using the app's managed identity, so the secret value never appears in the YAML, image, or environment in plaintext. This centralizes secret management, enables rotation without redeploying, and provides audit trails. It is the recommended pattern for sensitive API keys in Container Apps.

Exam trap

AI-200 often tests that 'environment variables in YAML' and 'hardcoded in code' are insecure, so candidates must recognize Key Vault references with managed identity as the only secure option among the choices.

How to eliminate wrong answers

Option A is wrong because environment variables in the YAML are stored in plaintext in the revision template and visible to anyone with read access to the resource — not secure for API keys. Option B is wrong because hardcoding secrets in code embeds them in the image and source control, the worst possible practice. Option C is wrong because a sidecar container is just another process in the same pod; it does not provide secure secret storage or access control by itself.

Practice this question →

MCQmedium

You are running an AI inference workload in an Azure Kubernetes Service (AKS) cluster. The pods require access to an Azure Machine Learning workspace data store via managed identity without storing credentials in code. Which Kubernetes feature should you configure?

A.Azure CNI Overlay

B.Kubernetes Secrets CSI driver

C.Node-level Managed Identity

D.Azure AD Workload Identity

AnswerD

Workload Identity federates a Kubernetes service account with a Microsoft Entra ID identity via OIDC, letting pods obtain tokens for the Azure Machine Learning data store without embedded credentials. This satisfies the no-stored-credentials constraint, unlike pod-managed identity or secrets.

Why this answer

Azure AD Workload Identity federates a Kubernetes service account with an Azure AD application (or user-assigned managed identity) using OIDC, allowing pods to obtain Azure AD tokens without storing secrets. This is the supported, recommended way for AKS pods to access Azure resources like an AML workspace data store using managed identity.

Exam trap

AI-200 often tests the distinction between node-level managed identity (shared by all pods, discouraged) and Azure AD Workload Identity (per-pod, OIDC-federated), luring candidates toward the simpler but insecure node-level option.

How to eliminate wrong answers

Option A is wrong because Azure CNI Overlay is a networking plugin that changes pod IP addressing (pods get IPs from an overlay CIDR rather than the VNet), unrelated to identity or credential management. Option B is wrong because the Secrets Store CSI driver mounts secrets from Key Vault as volumes — it still relies on an identity to authenticate to Key Vault and is not the mechanism that provides the managed identity itself. Option C is wrong because node-level managed identity assigns an identity to the VMSS nodes, meaning every pod on the node shares that identity — it violates least privilege and is explicitly discouraged for multi-tenant or per-workload access.

Practice this question →

MCQmedium

You are optimizing an AI model container image size. Which technique is most effective for reducing the footprint of an image based on a large Python deep learning framework?

A.Implement multi-stage Docker builds.

B.Enable ACR Georeplication.

C.Store model weights as image layers.

D.Use the 'latest' tag for all base images.

AnswerA

Multi-stage builds let you compile and install dependencies in a builder stage, then copy only the runtime artefacts into a slim final image, discarding build tooling, caches and source layers that otherwise bloat a framework-based Python image.

Why this answer

Multi-stage Docker builds let you compile/install dependencies in a builder stage and copy only the runtime artifacts into a slim final stage, discarding build tools, caches, and intermediate files. For a large Python deep learning framework (e.g., PyTorch/TensorFlow), this can cut image size dramatically because compilers, pip caches, and dev headers never reach the final image. It is the standard technique for shrinking ML container images without losing functionality.

Exam trap

AI-200 often tests the misconception that registry-level features (georeplication, tagging) reduce image size, when only build-time techniques like multi-stage builds actually change the image footprint.

How to eliminate wrong answers

Option B is wrong because ACR Georeplication replicates a registry across regions for latency/availability; it does not change the size of any image. Option C is wrong because storing model weights as image layers adds to the image size rather than reducing it, and weights are better mounted from external storage or downloaded at runtime. Option D is wrong because using the 'latest' tag is an anti-pattern that harms reproducibility and does not reduce image footprint at all.

Practice this question →

MCQmedium

You are troubleshooting an AI inference container in Azure Container Apps that fails to start because it cannot pull the base image from Azure Container Registry. Authentication fails with an unauthorized error. What is the recommended way to grant the Container App access to ACR?

A.Hardcode the admin username and password into environment variables

B.Configure a system-assigned managed identity on the Container App and assign the AcrPull role on ACR

C.Expose the ACR endpoint publicly without authentication

D.Attach an Azure Storage Account SAS token to the container environment

AnswerB

A system-assigned managed identity gives the Container App an Microsoft Entra ID identity, and assigning the AcrPull role on the registry authorises image pulls without storing credentials. This eliminates the unauthorised error while avoiding secrets in configuration, which is the recommended passwordless approach.

Why this answer

The recommended approach is to enable a system-assigned (or user-assigned) managed identity on the Container App and grant it the AcrPull role on the Azure Container Registry. This lets the Container App authenticate to ACR without storing any credentials, using Entra ID token exchange under the hood. It is the Azure-native, secretless pattern for image pulls.

Exam trap

AI-200 often tests whether candidates default to admin credentials or SAS tokens for ACR access, when the correct Azure-native answer is always a managed identity with the AcrPull role.

How to eliminate wrong answers

Option A is wrong because hardcoding admin credentials into environment variables exposes secrets in configuration and logs, and ACR admin accounts are disabled by default for security reasons. Option C is wrong because exposing ACR publicly without authentication allows anyone to pull images and violates basic supply-chain security. Option D is wrong because an Azure Storage SAS token grants access to blob storage, not to ACR — ACR authentication uses Entra ID or ACR tokens, not storage SAS tokens.

Practice this question →

MCQmedium

You are deploying a distributed PyTorch training job across multiple nodes in an Azure Kubernetes Service (AKS) cluster. Which mechanism should you use to facilitate high-speed, low-latency inter-node communication required for gradient synchronization?

A.Kubenet basic networking with dynamic NAT

B.Node placement with GPU-optimized VM series (such as NDm A100 v4) and InfiniBand support

C.Azure Application Gateway Ingress Controller (AGIC)

D.Standard Azure CNI with Network Policies enabled

AnswerB

InfiniBand with NDm A100 v4 provides the RDMA fabric that carries NCCL gradient-synchronisation traffic between nodes at high bandwidth and low latency. Standard Ethernet interconnect cannot meet the all-reduce demands of distributed PyTorch training, so this placement satisfies the inter-node communication constraint.

Why this answer

Distributed PyTorch training requires high-bandwidth, low-latency inter-node communication for AllReduce gradient synchronization, and InfiniBand (via RDMA) on GPU-optimized VM series like NDm A100 v4 provides exactly that. These SKUs include dedicated InfiniBand fabric that bypasses the TCP/IP stack, delivering the microsecond latency and hundreds of Gbps throughput needed to keep GPUs from starving during gradient exchange.

Exam trap

AI-200 often tests the misconception that any Azure CNI or ingress configuration improves inter-node performance, when only RDMA-capable GPU SKUs with InfiniBand address gradient synchronization latency.

How to eliminate wrong answers

Option A is wrong because kubenet with dynamic NAT is a basic overlay network for pod IP routing and offers no RDMA or high-speed fabric, so gradient synchronization would bottleneck on standard TCP. Option C is wrong because AGIC is an L7 HTTP/HTTPS ingress controller for exposing web applications, completely unrelated to inter-node GPU communication. Option D is wrong because standard Azure CNI with Network Policies provides pod IP addressing and traffic filtering but runs over regular Ethernet with no RDMA/InfiniBand acceleration for collective operations.

Practice this question →

MCQeasy

Your data science team pushes container images to Azure Container Registry (ACR). You need to ensure that every image pushed is automatically scanned for known vulnerabilities before being deployed to production. Which ACR feature should you enable?

A.Microsoft Defender for Cloud vulnerability scanning

B.ACR Tasks

C.Azure Policy geo-replication rules

D.Content Trust signing

AnswerA

Microsoft Defender for Cloud vulnerability scanning integrates with ACR to automatically scan images on push, detecting known CVEs in OS packages and language dependencies. Enabling it satisfies the requirement to scan every pushed image before production deployment without altering the build pipeline.

Why this answer

Microsoft Defender for Cloud (specifically the Defender for Containers plan) integrates with ACR to automatically scan images on push and continuously rescan for newly disclosed CVEs. Findings surface as security recommendations and can gate deployment via Azure Policy. This is the native ACR vulnerability-scanning capability the question asks for.

Exam trap

The trap is confusing build automation (ACR Tasks) or signing (Content Trust) with vulnerability scanning; only Defender for Cloud performs CVE detection on pushed images.

How to eliminate wrong answers

Option B is wrong because ACR Tasks automates image builds, base-image updates, and multi-step workflows, but does not perform vulnerability scanning. Option C is wrong because Azure Policy geo-replication rules govern where registries replicate data for availability/compliance, not image scanning. Option D is wrong because Content Trust (Docker Notary) enforces image signing and integrity verification, which proves provenance but does not detect known vulnerabilities.

Practice this question →

Multi-Selecthard

Which THREE of the following are benefits of using ACR Tasks for containerized AI workloads?

Select 3 answers

A.Automatic scaling of the registry.

B.Triggering builds on base image updates.

C.Automated image building from source code.

D.Multi-step build tasks.

E.Direct deployment to Azure SQL.

AnswersB, C, D

ACR Tasks can automatically rebuild an image whenever its base image is updated in the registry, removing manual rebuild effort. This directly satisfies the stem's benefit requirement by keeping containerised AI workloads current with patched or retrained base layers, without external CI orchestration or scheduled pipelines.

Why this answer

Option B is correct because ACR Tasks can automatically trigger a rebuild of an image whenever its base image is updated in the registry, which keeps containerized AI workloads current with patched or upgraded dependencies. Option C is correct because ACR Tasks provides automated image building from source code, using a Dockerfile or buildpacks, so commits to a Git repository or source archive can produce new container images without a local Docker daemon. Option D is correct because ACR Tasks supports multi-step tasks, defined in a YAML file, that chain build, run, and push steps for complex container workflows.

Option A is not a benefit of ACR Tasks, since automatic scaling of the registry is a feature of the Azure Container Registry service tier (for example, Premium with geo-replication and throughput scaling), not of ACR Tasks. Option E is not applicable because ACR Tasks builds and manages container images; it does not directly deploy to Azure SQL, which is a relational database service rather than a container deployment target.

Exam trap

AI-200 often tests whether candidates confuse ACR Tasks (a build automation service) with registry scaling or deployment services — the distractor 'automatic scaling of the registry' sounds plausible but is not a feature of ACR Tasks.

Practice this question →

MCQhard

You are optimizing a large language model container inference deployment on AKS using GPU-enabled nodes (NC-series). The inference server experiences frequent out-of-memory errors on the GPU device itself during high context lengths. Which Kubernetes configuration metric should you monitor and alert on?

A.container_memory_working_set_bytes via kubelet

B.container_cpu_cfs_throttled_periods_total

C.node_net_bytes_total

D.container_gpu_memory_used_bytes via NVIDIA DCGM Exporter

AnswerD

container_gpu_memory_used_bytes, exposed by NVIDIA DCGM Exporter, reports actual GPU device memory consumption. Monitoring it directly detects the high-context-length memory pressure causing device-level out-of-memory errors, unlike node-level or CPU metrics which cannot reveal GPU memory exhaustion.

Why this answer

GPU out-of-memory errors on the device itself must be detected by monitoring GPU memory utilization, which is exposed by the NVIDIA DCGM Exporter as container_gpu_memory_used_bytes (and related DCGM metrics like DCGM_FI_DEV_FB_USED). This metric reflects actual framebuffer memory consumption on the GPU, which is what causes CUDA OOM errors during long-context inference.

Exam trap

The trap is conflating container memory (RAM) with GPU device memory — candidates pick container_memory_working_set_bytes because it sounds like 'memory used,' missing that GPU OOM requires a DCGM/NVIDIA-specific metric.

How to eliminate wrong answers

Option A is wrong because container_memory_working_set_bytes measures host/container RAM (system memory), not GPU framebuffer memory — a pod can have low working set and still OOM on the GPU. Option B is wrong because container_cpu_cfs_throttled_periods_total measures CPU scheduling throttling, which is unrelated to GPU memory exhaustion. Option C is wrong because node_net_bytes_total is a network throughput metric and has no bearing on GPU memory.

Practice this question →

MCQeasy

You need to store sensitive database connection strings and AI API keys used by containerized applications running in Azure Container Apps. Which feature should you use to securely store and reference these values?

A.A standard DNS TXT record

B.Container App Secrets

C.Azure Storage account public blob container

D.Plain text Dockerfile ENV directives

AnswerB

Container App Secrets store encrypted values at the application level and expose them to containers as environment variables or volume-mounted references, keeping connection strings and API keys out of images and source control. This satisfies the secure storage and reference requirement.

Why this answer

Container App Secrets provide an encrypted, managed store for sensitive values such as connection strings and API keys, and they can be referenced from environment variables or volume mounts without exposing the plaintext in the app definition. They are scoped to the Container App and integrated with the platform's secret management, making them the correct secure storage mechanism.

Exam trap

AI-200 often tests the misconception that environment variables in the container definition are secure, when only Container App Secrets (or Key Vault references) provide encrypted, redacted storage.

How to eliminate wrong answers

Option A is wrong because a DNS TXT record is publicly resolvable and provides no confidentiality or access control, exposing secrets to anyone who queries the record. Option C is wrong because a public blob container allows anonymous read access, directly leaking the secrets to the internet. Option D is wrong because Dockerfile ENV directives bake plaintext secrets into the image layers, where they persist in the registry and are visible to anyone with image pull access.

Practice this question →