Courseiva

CCNA Containerized Ai Workloads Questions

30 of 105 questions · Page 2/2 · Containerized Ai Workloads topic · Answers revealed

Practice these questionsExam hubAll questions
76
MCQeasy

Which command-line interface tool is used to deploy and manage container images directly to Azure Container Registry?

A.helm.
B.docker build.
C.az acr.
D.kubectl.
AnswerC

The az acr command group within the Azure CLI provides dedicated operations for building, pushing, importing and managing container images in Azure Container Registry, meeting the need to deploy and manage images directly against the registry.

Why this answer

The Azure CLI command group 'az acr' is specifically designed to manage Azure Container Registry, including building, pushing, and pulling container images directly to/from ACR. It provides native integration with ACR and supports tasks like creating registries, managing credentials, and running ACR Tasks. This makes it the correct tool for deploying and managing container images directly to ACR.

Exam trap

AI-200 often tests the difference between general container tools (Docker, Helm, kubectl) and Azure-specific management tools (az acr), causing candidates to choose a tool that builds images locally but does not directly manage ACR.

How to eliminate wrong answers

Option A is wrong because Helm is a package manager for Kubernetes, used to deploy applications, not to manage container images in ACR. Option B is wrong because 'docker build' builds images locally but does not deploy or manage them in ACR; you would still need 'docker push' or 'az acr' to push. Option D is wrong because kubectl is a Kubernetes command-line tool for managing clusters, not for directly managing container images in ACR.

Practice this question →
77
MCQhard

You are deploying a high-performance AI model in AKS. You need to ensure the container has access to the underlying host's NVIDIA GPU. What must be configured in the Pod spec?

A.Mount the host path '/dev/nvidia0'.
B.Use an InitContainer to install the driver.
C.Set 'privileged: true' in the security context.
D.Define a Resource Request for 'nvidia.com/gpu'.
AnswerD

Requesting 'nvidia.com/gpu' as a resource limit in the container spec triggers the NVIDIA device plugin to allocate a host GPU and mount the driver libraries. This satisfies the requirement that the container accesses the underlying host NVIDIA GPU.

Why this answer

To give a container access to an NVIDIA GPU in Kubernetes/AKS, you must declare a resource request (and typically a limit) for `nvidia.com/gpu` in the container spec. The NVIDIA device plugin on the node advertises GPUs as extended resources, and the scheduler uses this request to bind the pod to a GPU-equipped node and allocate the device.

Exam trap

AI-200 often tests the difference between host-level GPU access (mounting devices, privileged mode) and Kubernetes-native resource requests, tricking candidates who pick low-level workarounds.

How to eliminate wrong answers

Option A is wrong because mounting `/dev/nvidia0` directly bypasses the device plugin, does not properly allocate or isolate the GPU, and is not how Kubernetes manages GPU resources — it can also cause conflicts between pods. Option B is wrong because installing the driver via an InitContainer is not the mechanism for GPU access; the NVIDIA driver must be installed on the host (AKS GPU node pools handle this), and the device plugin exposes the GPU. Option C is wrong because `privileged: true` grants broad host access but does not allocate a GPU as a schedulable resource — it is a security risk and not the correct GPU access method.

Practice this question →
78
MCQmedium

You are setting up auto-scaling for a containerized AI web app in Azure Container Apps. You want to scale based on the number of concurrent HTTP requests. Which scaler do you use?

A.Azure Service Bus scaler.
B.HTTP scaler.
C.CPU usage scaler.
D.Memory usage scaler.
AnswerB

The HTTP scaler scales replicas based on the number of concurrent HTTP requests reaching the app, which matches the stated concurrency metric. It reads request counts directly, so scaling responds to actual traffic load rather than CPU or memory usage.

Why this answer

The HTTP scaler in Azure Container Apps scales replicas based on the number of concurrent HTTP requests, which directly matches the requirement to scale on concurrent HTTP request count. It is a KEDA-based scaler configured in the container app's scale rules with a `concurrentRequests` threshold.

Exam trap

The trap is that candidates may choose CPU or memory scalers because they assume resource utilization is the best proxy for load, but AI-200 tests the specific scaler type that directly measures HTTP concurrency.

How to eliminate wrong answers

Option A is wrong because the Azure Service Bus scaler scales on message queue length or topic subscription backlog, which is appropriate for asynchronous messaging, not concurrent HTTP requests. Option C is wrong because CPU usage reflects compute consumption inside the container, not the number of simultaneous inbound HTTP connections, and it may lag behind actual request concurrency. Option D is wrong because memory usage is a resource metric that does not correlate directly with HTTP request concurrency and can be affected by caching or leaks unrelated to traffic.

Practice this question →
79
MCQhard

You notice that your AKS pods are stuck in 'ContainerCreating' state. You check the events and see 'FailedMount'. What is the most likely cause?

A.The node is out of CPU resources.
B.The container crashed immediately.
C.The container image is too large.
D.The associated Persistent Volume Claim (PVC) is missing or cannot be bound.
AnswerD

FailedMount events occur when the kubelet cannot attach or mount the volume backing a pod. A missing or unbound Persistent Volume Claim leaves no storage to mount, so the pod remains in ContainerCreating. This matches the observed event rather than image or scheduling faults.

Why this answer

A 'FailedMount' event during the ContainerCreating phase almost always indicates that the pod's volume mount could not be satisfied — most commonly because the PersistentVolumeClaim (PVC) is missing, in a Pending state, or cannot bind to an available PersistentVolume. Since the container hasn't started yet, the failure is at the storage attachment stage, not at runtime. This is the classic signature of a PVC/PV binding problem in AKS.

Exam trap

AI-200 often tests whether candidates can distinguish between scheduling failures (Pending), image pull failures (ImagePullBackOff), runtime crashes (CrashLoopBackOff), and volume mount failures (FailedMount) — the trap is picking a resource-exhaustion answer when the event explicitly names a mount problem.

How to eliminate wrong answers

Option A is wrong because CPU exhaustion causes pods to remain in Pending (scheduler cannot place them) or triggers eviction/OOMKilled at runtime — it does not produce a FailedMount event. Option B is wrong because a container crash manifests as CrashLoopBackOff or Error status after the container has started, not as a mount failure during ContainerCreating. Option C is wrong because a large image causes slow image pulls (ImagePullBackOff or long ContainerCreating delays) but does not generate a FailedMount event tied to volume attachment.

Practice this question →
80
Multi-Selecteasy

Which TWO of the following are valid ways to authenticate an AKS cluster to an Azure Container Registry?

Select 2 answers
A.Azure Managed Identity.
B.Azure Active Directory Service Principal.
C.Azure Monitor.
D.Hardcoded Docker config file.
E.Azure Policy.
AnswersA, B

Azure Managed Identity lets the AKS cluster's kubelet identity authenticate to Azure Container Registry without storing credentials, satisfying the stem's requirement for a valid authentication method. The acrPull role assignment on the managed identity grants image pull permissions, eliminating secret rotation overhead.

Why this answer

Option A (Azure Managed Identity) is correct because AKS can use a system-assigned or user-assigned managed identity to authenticate to ACR via the AcrPull role assignment, eliminating stored credentials; the kubelet identity is granted the AcrPull role on the registry. Option B (Azure Active Directory Service Principal) is correct because you can create an AAD service principal, assign it the AcrPull role on the ACR, and store its appId/password as a Kubernetes imagePullSecret referenced by the pod spec. Option C (Azure Monitor) is incorrect because it is a monitoring/observability service, not an authentication mechanism for pulling images.

Option D (Hardcoded Docker config file) is incorrect because embedding credentials in a plaintext docker config.json is insecure and not a supported AKS-to-ACR authentication method. Option E (Azure Policy) is incorrect because it enforces governance/compliance rules, not registry authentication.

Exam trap

AI-200 often tests the distinction between authentication mechanisms and monitoring/governance services, tricking candidates into selecting Azure Monitor or Azure Policy because they sound like they 'control' access.

Practice this question →
81
Multi-Selectmedium

Which TWO of the following features help manage traffic to containerized applications?

Select 2 answers
A.Azure Monitor.
B.Azure Key Vault.
C.Service Mesh (Istio/Linkerd).
D.Azure Blob Storage.
E.Kubernetes Ingress Controller.
AnswersC, E

A service mesh such as Istio or Linkerd injects sidecar proxies alongside each pod, giving layer-7 traffic management: dynamic routing, retries, timeouts, mutual TLS and observability between services. This satisfies the requirement to manage east-west traffic between containerised applications independently of application code.

Why this answer

A Service Mesh such as Istio or Linkerd (option C) is correct because it provides layer-7 traffic management for containerized workloads, including intelligent routing, load balancing, traffic splitting for canary/blue-green deployments, retries, timeouts, and mutual TLS between pods via sidecar proxies. A Kubernetes Ingress Controller (option E) is correct because it exposes HTTP/HTTPS routes from outside the cluster to Services inside the cluster, performing host- and path-based routing, TLS termination, and load balancing to containerized applications. Azure Monitor (option A) is an observability platform for metrics, logs, and alerts, not a traffic-routing mechanism.

Azure Key Vault (option B) is a secrets, keys, and certificate management service, unrelated to directing application traffic. Azure Blob Storage (option D) is object storage for unstructured data and does not manage or route network traffic to containers.

Exam trap

AI-200 often tests the confusion between observability tools (Azure Monitor) and traffic management tools (Ingress, service mesh) — candidates pick Azure Monitor because it 'manages' something, but it does not route traffic.

Practice this question →
82
Multi-Selecthard

Which TWO of the following techniques help optimize the performance of containerized AI models in AKS?

Select 2 answers
A.Tune pod resource limits and requests.
B.Disable all logging.
C.Use the standard CNI instead of Azure CNI.
D.Increase the replica count to 100 for all services.
E.Use dedicated node pools for GPU tasks.
AnswersA, E

Tuning pod resource requests and limits directly addresses the CPU and memory constraints that throttle containerised inference in AKS. Accurate requests let the scheduler place pods on nodes with sufficient capacity, while limits prevent noisy-neighbour contention, sustaining the throughput and latency the stem's performance objective demands.

Why this answer

Option A is correct because setting accurate CPU and memory requests lets the AKS scheduler place pods on nodes with sufficient capacity, while proper limits prevent noisy-neighbor contention and OOMKills, directly improving the stability and throughput of containerized AI inference or training workloads. Option E is correct because dedicating node pools with GPU-enabled VM SKUs (e.g., NC/ND series) to GPU tasks ensures AI pods get exclusive access to GPU resources, avoids scheduling conflicts with CPU-only workloads, and allows independent scaling and taints/tolerations for GPU nodes. Option B is wrong because disabling all logging removes observability needed to diagnose performance bottlenecks and does not improve runtime performance.

Option C is wrong because switching from Azure CNI to standard (kubenet) CNI does not optimize AI model performance and can reduce networking capabilities. Option D is wrong because blindly increasing replicas to 100 for all services wastes resources, can cause scheduling pressure and cost blowups, and does not address per-pod performance.

Exam trap

AI-200 often tests the misconception that 'more replicas always means better performance' or that networking/logging changes are performance optimizations, when the real levers are resource tuning and workload isolation via dedicated node pools.

Practice this question →
83
MCQhard

You are integrating Azure Container Registry with Azure Kubernetes Service. You want to enable authentication without storing static credentials (username/password) in Kubernetes secrets. What is the recommended integration method?

A.Store ACR admin credentials in a Kubernetes Secret object
B.Configure a Docker daemon config.json file on every node manually
C.Attach the ACR to the AKS cluster using Azure CLI attachment command
D.Enable anonymous pull on the Azure Container Registry
AnswerC

Attaching the registry with the Azure CLI attachment command configures the AKS kubelet identity with the AcrPull role assignment, so nodes pull images using managed identity tokens. This satisfies the no-static-credentials constraint, unlike imagePullSecrets or admin account keys.

Why this answer

Attaching ACR to AKS using the Azure CLI (az aks update --attach-acr) configures the cluster's kubelet managed identity with the AcrPull role on the registry, enabling image pulls without static credentials. This is the native, supported integration that eliminates the need for Kubernetes image pull secrets.

Exam trap

AI-200 often tests whether candidates know that AKS-ACR integration uses managed identity and RBAC (AcrPull) rather than Kubernetes secrets, tempting them to pick the familiar imagePullSecret pattern.

How to eliminate wrong answers

Option A is wrong because storing ACR admin credentials in a Kubernetes Secret reintroduces static credentials, which the scenario explicitly wants to avoid, and admin credentials are all-or-nothing. Option B is wrong because manually configuring a Docker config.json on every node is operationally fragile, does not survive node scaling, and still embeds credentials. Option D is wrong because anonymous pull makes the registry publicly readable, which is a security risk and not an authentication integration.

Practice this question →
84
MCQmedium

You have an AI scoring script that runs periodically. You want to execute this containerized workload on a schedule without managing virtual machines. Which Azure service is best suited for running containerized batch jobs on a schedule?

A.Azure Kubernetes Service CronJobs
B.Azure Container Instances with restart policy Always
C.Azure Functions with HTTP triggers
D.Azure Container Apps Jobs
AnswerD

Azure Container Apps Jobs runs containerised tasks on cron or event triggers with no VM or cluster management, satisfying the scheduled batch requirement. Unlike plain Container Apps, Jobs are designed for run-to-completion workloads rather than long-running services.

Why this answer

Azure Container Apps Jobs is correct because it is a serverless container execution service that supports scheduled (cron) and event-driven jobs without managing VMs or Kubernetes infrastructure. You define a container image, a cron schedule, and resource limits, and Azure handles the orchestration, scaling, and execution — ideal for periodic AI scoring scripts packaged as containers.

Exam trap

AI-200 often tests the confusion between AKS CronJobs and Container Apps Jobs — candidates pick AKS because 'CronJob' sounds purpose-built, ignoring the requirement to avoid managing VMs and infrastructure.

How to eliminate wrong answers

Option A is wrong because AKS CronJobs require you to provision, manage, and pay for an AKS cluster (nodes, upgrades, networking) — the question explicitly asks to avoid managing VMs, and AKS is a heavier operational burden. Option B is wrong because Azure Container Instances with restart policy 'Always' runs a container continuously and restarts it on exit; it is not a scheduling mechanism and would run the job perpetually rather than on a schedule. Option C is wrong because Azure Functions with HTTP triggers execute on HTTP requests, not on a schedule, and are code-first (not containerized batch jobs by default); a Timer trigger would be needed for scheduling, and Functions is not the best fit for arbitrary containerized batch workloads.

Practice this question →
85
MCQmedium

You are deploying a containerized AI inference API to Azure Container Apps. The container must read model files from an Azure Files share and write temporary logs to the same share. You need to configure the Container App so the share is available at a specific mount path inside the container. What should you do?

A.Configure an Azure File share as a bind mount by adding it to the Dockerfile VOLUME instruction.
B.Use the Azure CLI command az containerapp storage add to mount the share into the running container instance.
C.Attach the Azure Files share directly to the Container App using the Azure portal's 'Networking' blade.
D.Create an Azure Files storage definition in the Container Apps environment and add a volume mount to the Container App revision.
AnswerD

Azure Container Apps supports mounting Azure Files shares by defining a storage resource at the environment level and then referencing it as a volume with a mount path in the container app. This makes the share available to the container at the specified path, allowing the AI workload to read model files and write logs persistently across revisions.

Why this answer

To make an Azure Files share available to a Container App, you must first define the storage at the Container Apps environment level, then reference it as a volume and specify a mount path in the container app revision. This enables the AI workload to persist model files and logs. Other options either refer to non-existent features or confuse container-local volumes with external Azure Files mounts.

Exam trap

The trap here is assuming that Dockerfile VOLUME instructions or portal networking settings can mount an external Azure Files share, when Azure Container Apps requires environment-level storage definitions and volume mounts.

Practice this question →
86
MCQmedium

You have an AI model container hosted in Azure Container Registry. You want to ensure that every container image pushed to the registry is automatically scanned for known vulnerabilities before deployment. Which ACR feature should you enable?

A.ACR Tasks auto-purge
B.Content Trust
C.ACR geo-replication
D.Microsoft Defender for Cloud vulnerability scanning
AnswerD

Defender for Cloud's registry integration scans images on push, surfacing OS and language-package vulnerabilities per digest. Enabling it satisfies the requirement that every pushed image is automatically assessed before deployment, without altering the build pipeline.

Why this answer

Microsoft Defender for Cloud vulnerability scanning is correct because it provides integrated image vulnerability assessment for Azure Container Registry, automatically scanning images on push and continuously re-scanning for newly disclosed CVEs. Enabling the Defender for Containers plan surfaces scan results in Defender for Cloud and can gate deployments via Azure Policy. This directly satisfies the requirement to scan every pushed image before deployment.

Exam trap

AI-200 often tests the confusion between registry security features — candidates pick Content Trust thinking 'security' means scanning, when Content Trust only handles image signing and integrity, not CVE detection.

How to eliminate wrong answers

Option A is wrong because ACR Tasks auto-purge is a retention/cleanup feature that deletes old or untagged images based on a schedule or count — it has nothing to do with vulnerability scanning. Option B is wrong because Content Trust (Docker Content Trust/Notary) enforces image signing and verification so only signed images can be pulled; it ensures integrity and provenance but does not detect vulnerabilities. Option C is wrong because ACR geo-replication replicates a registry across multiple Azure regions for latency and availability — it is a distribution feature, not a security scanning feature.

Practice this question →
87
MCQhard

You are running a containerized AI inference service on Azure Kubernetes Service (AKS). The service uses a large language model and requires 24 GB of GPU memory. You have a node pool with NVIDIA V100 GPUs (16 GB each). You need to ensure the pod can access sufficient GPU memory. What should you do?

A.Configure the pod to request `nvidia.com/gpu: 2` in its resource limits.
B.Increase the memory limit of the pod to 24 GB and set the `NVIDIA_VISIBLE_DEVICES` environment variable to `all`.
C.Enable GPU sharing by setting the `nvidia.com/gpu` resource to `0.5` to allow two pods to share a GPU.
D.Use a node pool with GPUs that have at least 24 GB of memory, such as NVIDIA A100 (40 GB) or V100 (32 GB), and request one GPU.
AnswerD

The inference service requires 24 GB of GPU memory. To meet this, you need a GPU with at least 24 GB of memory per device. NVIDIA A100 (40 GB) or V100 (32 GB) satisfy this. Requesting one GPU from such a node pool ensures the pod gets a single GPU with sufficient memory, which is the simplest and most reliable solution.

Why this answer

The inference service requires 24 GB of GPU memory. The existing V100 GPUs have only 16 GB, so a single GPU is insufficient. The correct approach is to use a node pool with GPUs that have at least 24 GB, such as A100 (40 GB) or V100 (32 GB), and request one GPU.

This provides the necessary memory without requiring multi-GPU programming.

Exam trap

The trap here is assuming that requesting multiple GPUs or increasing pod memory limits will provide more GPU memory to a single container, when GPU memory is per-device.

Practice this question →
88
MCQeasy

You want to limit the CPU resources that a specific AI inference pod can consume. Which Kubernetes field do you configure?

A.resources.requests.
B.securityContext.
C.resources.limits.
D.livenessProbe.
AnswerC

resources.limits caps the maximum CPU a container may consume, directly satisfying the requirement to limit a specific inference pod's CPU. It differs from resources.requests, which only reserves scheduling capacity and does not enforce an upper ceiling.

Why this answer

The `resources.limits` field in a Kubernetes pod spec sets the maximum CPU and memory a container can consume. When a container exceeds its CPU limit, it is throttled; when it exceeds its memory limit, it is OOM-killed. This is the correct field to cap CPU for an inference pod.

Exam trap

The trap is confusing requests with limits; AI-200 tests whether you know requests are for scheduling guarantees while limits enforce the maximum consumption ceiling.

How to eliminate wrong answers

Option A is wrong because `resources.requests` sets the minimum guaranteed resources for scheduling, not a maximum cap. Option B is wrong because `securityContext` defines privilege and access controls, not resource consumption. Option D is wrong because `livenessProbe` determines container health and restart behavior, not CPU limits.

Practice this question →
89
Multi-Selectmedium

You are deploying an AI model container in Azure Container Apps. Which TWO authentication mechanisms can you configure for securely pulling the image from a private Azure Container Registry?

Select 2 answers
A.ACR administrator username and password
B.Azure Active Directory client certificate stored in public DNS
C.Azure Storage account connection string
D.System-assigned managed identity
E.Anonymous public pull token
AnswersA, D

ACR administrator credentials authenticate registry pulls using the registry-level admin account, satisfying the private registry access requirement without needing Microsoft Entra integration. Container Apps accepts these as a registry credential when configuring the image source, though the shared account lacks per-identity scoping.

Why this answer

Option A (ACR administrator username and password) is correct because Azure Container Apps supports registry authentication using the registry's admin credentials, which are enabled on the ACR and supplied as username/password when configuring the registry in the container app. Option D (System-assigned managed identity) is correct because Container Apps can use a managed identity with the AcrPull role assignment on the registry, allowing image pulls without storing secrets. Option B is incorrect because a client certificate in public DNS is not a supported ACR authentication mechanism and public DNS is not a secure credential store.

Option C is incorrect because an Azure Storage account connection string authenticates to Blob/File storage, not to Azure Container Registry. Option E is incorrect because anonymous public pull tokens do not provide authenticated access to a private registry.

Exam trap

The trap here is that candidates see 'client certificate' or 'connection string' and assume any credential type works for ACR, but ACR authentication is specifically limited to Azure AD identities, admin credentials, or scoped tokens — not storage keys or certificates.

Practice this question →
90
MCQhard

You are running a containerized AI image classification service on Azure Kubernetes Service (AKS). The service must process images from an Azure Blob Storage account. You want the pods to access the storage without embedding credentials in the container image or Kubernetes secrets. Which authentication method should you use?

A.Configure the pod to use the AKS cluster's kubelet managed identity to access Blob Storage.
B.Enable Azure AD Pod Identity and assign a managed identity to the pod.
C.Use Azure Workload Identity to federate a Kubernetes service account with an Azure AD managed identity.
D.Store the storage account key in a Kubernetes Secret and mount it as an environment variable in the pod.
AnswerC

Azure Workload Identity is the recommended way to enable pods to access Azure resources without secrets. It federates a Kubernetes service account with an Azure AD managed identity, allowing the pod to obtain Azure AD tokens. This eliminates credential storage in images or secrets and provides fine-grained access control to Blob Storage.

Why this answer

Azure Workload Identity allows Kubernetes pods to authenticate to Azure services using a federated identity, avoiding secrets. It is the modern replacement for Azure AD Pod Identity and is the recommended method for credential-less access. Other options either use deprecated methods, store secrets, or misuse the kubelet identity, which does not provide the desired per-pod access control.

Exam trap

The trap here is confusing the kubelet managed identity, which operates at the node level for infrastructure tasks, with a pod-level identity for application access to Azure resources.

Practice this question →
91
MCQmedium

You are deploying an AI model container to Azure Container Apps. The container application needs to securely connect to an Azure SQL Database without storing plain-text database credentials in environment variables or application code. What is the recommended feature to use?

A.Azure Key Vault references with managed identity
B.Azure Container Registry admin credentials
C.Container Apps encrypted environment variables
D.Kubernetes secrets mapped via sidecar proxy
AnswerA

Azure Key Vault references with managed identity let Container Apps retrieve secrets at runtime, so no plain-text credentials sit in environment variables or code. The managed identity authenticates to Key Vault without stored secrets, satisfying the stem's constraint of avoiding plain-text database credentials.

Why this answer

Azure Key Vault references combined with a managed identity let the container retrieve secrets at runtime without embedding credentials in code or environment variables. The managed identity authenticates to Key Vault, and the Key Vault reference resolves the secret into the app's configuration securely.

Exam trap

AI-200 often tests whether candidates confuse 'encrypted at rest' with 'not stored in the app definition' — encrypted environment variables still contain the secret, so Key Vault references with managed identity is the only option that removes the secret from the app entirely.

How to eliminate wrong answers

Option B is wrong because ACR admin credentials are for pulling images from the registry, not for authenticating to Azure SQL, and using them would still require storing a static secret. Option C is wrong because Container Apps encrypted environment variables still store the secret in the app configuration — encryption at rest does not remove the secret from the deployment definition or prevent exposure. Option D is wrong because Kubernetes secrets mapped via a sidecar proxy is a Kubernetes pattern, not the native Container Apps recommended approach, and it still requires storing the secret somewhere.

Practice this question →
92
Multi-Selecthard

You are configuring secure ingress and network isolation for an Azure Container Apps environment. Which THREE capabilities are supported when configuring networking for Container Apps? (Choose three.)

Select 3 answers
A.Exposing the environment with either external (public) or internal (private VNet) ingress
B.Direct modification of physical Azure datacenter top-of-rack switches
C.Deploying the environment within a customer-managed Azure Virtual Network (VNet) subnet
D.Direct attachment of physical Fibre Channel storage SAN arrays
E.Configuring custom domain names with automated managed TLS/SSL certificates
AnswersA, C, E

Container Apps environments support both external ingress, which publishes apps on a public endpoint, and internal ingress, which restricts traffic to a private Azure Virtual Network. This directly satisfies the stem's requirement for secure ingress and network isolation, letting you choose public exposure or VNet-only access per environment.

Why this answer

Option A is correct because Azure Container Apps environments support both external ingress, which exposes apps to the public internet via a public endpoint, and internal ingress, which restricts access to a private VNet or the environment's internal network. Option C is correct because you can deploy a Container Apps environment into a customer-managed Azure Virtual Network subnet, enabling network isolation, private endpoints, and control over inbound/outbound traffic. Option E is correct because Container Apps supports custom domain names with automated managed TLS/SSL certificates, including free managed certificates for custom domains and binding of existing certificates.

Option B is incorrect because customers cannot directly modify physical Azure datacenter top-of-rack switches; Azure manages the physical network infrastructure. Option D is incorrect because attaching physical Fibre Channel SAN arrays is not a supported Container Apps networking capability; persistent storage in Container Apps is provided through Azure Files or managed storage abstractions, not direct SAN attachment.

Exam trap

AI-200 often tests whether candidates confuse Container Apps networking with IaaS-level controls — the trap is picking physical switch or SAN options, which are never customer-accessible in a PaaS service.

Practice this question →
93
MCQmedium

You want to track the latency of your model inference API in production. Which Azure tool should you integrate into your containerized application?

A.Azure Application Insights.
B.Azure Storage Queue.
C.Azure Event Hubs.
D.Azure Data Factory.
AnswerA

Application Insights provides request-level telemetry, dependency tracking and latency metrics for containerised workloads via its SDK or auto-instrumentation. It captures inference API response times and distributions, satisfying the stem's constraint of tracking production model inference latency in a containerised application.

Why this answer

Azure Application Insights is the Application Performance Management (APM) service within Azure Monitor, designed to capture request latency, dependency calls, exceptions, and custom telemetry from applications. Integrating the Application Insights SDK (or OpenTelemetry) into the containerized inference API automatically records request duration and end-to-end transaction traces. This directly answers the requirement to track inference API latency in production.

Exam trap

AI-200 often tests the distinction between telemetry/APM services (Application Insights) and data transport services (Event Hubs, Storage Queues), causing candidates to pick a messaging service for a monitoring requirement.

How to eliminate wrong answers

Option B is wrong because Azure Storage Queue is a messaging service for asynchronous decoupling, not a telemetry or latency-monitoring tool. Option C is wrong because Azure Event Hubs is a big-data streaming ingestion platform, not an APM solution — it can transport telemetry but does not measure or visualize latency. Option D is wrong because Azure Data Factory is an ETL/orchestration service for data pipelines and has no application performance monitoring capability.

Practice this question →
94
MCQhard

You are troubleshooting high latency in an AI inference workload on AKS. You suspect the issue is caused by container startup time (cold starts). Which feature helps mitigate this?

A.Configuring Vertical Pod Autoscaler.
B.Azure Container Registry Artifact Streaming.
C.Increasing the memory limit for the pod.
D.Using a smaller base OS distribution.
AnswerB

Artifact streaming pulls only the container layers needed to start, rather than downloading the full image first. This directly cuts image-pull time, the dominant contributor to cold-start latency for AKS inference pods, satisfying the stem's container startup constraint.

Why this answer

Azure Container Registry (ACR) Artifact Streaming (also called streaming artifacts) allows container image layers to be pulled on demand as the container starts, rather than downloading the entire image first. This dramatically reduces cold-start time for large AI inference images by letting the container begin execution while layers stream in the background. It directly addresses the container startup latency described.

Exam trap

AI-200 often tests whether candidates conflate resource scaling (VPA, memory limits) with image delivery optimization, causing them to pick autoscaling or resource-tuning answers when the root cause is image pull latency.

How to eliminate wrong answers

Option A is wrong because Vertical Pod Autoscaler adjusts CPU/memory requests and limits based on usage — it does not affect image pull or container startup time. Option C is wrong because increasing the memory limit addresses OOM issues or memory pressure, not cold-start latency from image download. Option D is wrong because using a smaller base OS distribution reduces image size and can help, but it is a build-time optimization, not a runtime feature that mitigates cold starts for existing large images; ACR Artifact Streaming is the targeted feature.

Practice this question →
95
MCQmedium

You are building a container image for an AI model that requires GPU acceleration. You plan to run it on Azure Kubernetes Service (AKS). Which step must you take to ensure the pods can access GPU resources?

A.Use a GPU-enabled node pool and set the container's runtime to nvidia in the Dockerfile.
B.Configure the pod to use the hostPath volume /dev/nvidia* to access the GPU devices directly.
C.Install the NVIDIA device plugin for Kubernetes and specify GPU resource limits in the pod specification.
D.Enable GPU support in the AKS cluster by setting the --enable-gpu flag during cluster creation.
AnswerC

To use GPUs in AKS, you must deploy the NVIDIA device plugin, which advertises GPU resources to the Kubernetes scheduler. Then, in the pod spec, you request nvidia.com/gpu resources. This allows the pod to be scheduled on a GPU node and access the GPU. Without the plugin, Kubernetes cannot allocate GPUs to pods.

Why this answer

To use GPUs in AKS, you must install the NVIDIA device plugin, which exposes GPU resources to Kubernetes. Then, in the pod spec, you request nvidia.com/gpu resources to schedule on GPU nodes. Other options either reference non-existent flags, rely on Dockerfile settings, or use unsafe hostPath mounts that bypass scheduling.

Exam trap

The trap here is thinking that a Dockerfile runtime directive or a cluster creation flag enables GPU access, when in fact the NVIDIA device plugin and resource requests are required.

Practice this question →
96
Multi-Selecthard

You are troubleshooting a containerized AI model deployment in Azure Container Apps that fails to pass its HTTP readiness probe. You need to inspect the container logs and runtime diagnostics. Which THREE tools or commands can you use to troubleshoot this issue? Each correct answer presents a complete solution.

Select 3 answers
A.Access the Azure Portal and use the Console diagnostic tool for the specific container app revision.
B.Run the az containerapp logs show Azure CLI command.
C.Query the Log Analytics workspace configured for the Container Apps environment.
D.Execute az aks browse to open the Kubernetes dashboard.
E.Use kubectl describe pod to inspect Kubernetes events.
AnswersA, B, C

The Console diagnostic tool opens an interactive shell in the running container app revision, letting you inspect processes, environment and probe endpoints directly. This provides runtime diagnostics for the failing HTTP readiness probe without redeploying the container.

Why this answer

Option A is correct because the Azure Portal's Console diagnostic tool for a specific container app revision opens an interactive shell inside the running container, letting you inspect the filesystem, processes, and probe-related runtime behavior directly. Option B is correct because 'az containerapp logs show' retrieves the system and console log streams for a container app (with parameters like --name, --resource-group, and --revision), which is exactly what you need to see why the HTTP readiness probe is failing. Option C is correct because Container Apps environments can send console and system logs to a Log Analytics workspace, where you can query them with KQL (for example, the ContainerAppConsoleLogs_CL and ContainerAppSystemLogs_CL tables) to diagnose probe failures.

Option D is not correct because 'az aks browse' targets Azure Kubernetes Service clusters, not Azure Container Apps, and it opens a Kubernetes dashboard rather than exposing container logs. Option E is not correct because 'kubectl describe pod' works against a Kubernetes API server and pods, whereas Container Apps is a serverless platform that abstracts away pods and does not expose them to kubectl.

Exam trap

AI-200 often tests whether candidates confuse Azure Container Apps with AKS, so any answer mentioning kubectl, the Kubernetes dashboard, or pod-level commands is a distractor because Container Apps hides the Kubernetes layer.

Practice this question →
97
MCQmedium

You need to deploy a set of batch AI processing containers in Azure Container Instances that run to completion and then terminate. Which container group restart policy should you select?

A.Always
B.Never
C.UnlessStopped
D.OnFailure
AnswerB

The Never restart policy ensures containers in the group run once to completion and are not restarted, matching the batch requirement that they terminate after finishing. Always would loop them indefinitely, and OnFailure would restart only failed containers, neither suiting run-to-completion jobs.

Why this answer

For Azure Container Instances running batch workloads that execute to completion and then terminate, the restart policy must be Never. This tells ACI not to restart the container after it exits, allowing the container group to reach a terminal Succeeded state. It is the correct choice for run-once batch AI processing jobs.

Exam trap

AI-200 often tests restart policy semantics, so the trap is choosing OnFailure thinking it means 'run once and stop,' when it actually restarts on any non-zero exit, or choosing Always for a batch job.

How to eliminate wrong answers

Option A is wrong because Always restarts the container continuously, which is appropriate for long-running services, not batch jobs that should terminate. Option C is wrong because UnlessStopped is not a valid ACI restart policy value — ACI supports Always, OnFailure, and Never only. Option D is wrong because OnFailure restarts the container only if it exits with a non-zero code, which is useful for retry-on-error but not for a job that should terminate after completion regardless of exit code.

Practice this question →
98
MCQhard

You are configuring TLS termination for an AI model API hosted in Azure Container Apps using a custom domain name. Where must you upload or configure the custom SSL certificate?

A.In the Container App custom domains settings using a Key Vault reference or uploaded certificate
B.In the Azure Container Registry webhook configuration
C.Inside the container image filesystem under /etc/ssl/certs
D.On the underlying Azure Container Instances node pool
AnswerA

Container Apps binds the custom domain's TLS certificate at the app's custom domains settings, accepting either an uploaded PFX or a Key Vault reference. Configuring it there satisfies the custom domain TLS termination requirement; Front Door or an App Service plan is not involved.

Why this answer

In Azure Container Apps, TLS termination for a custom domain is configured at the Container App (or its managed environment) level: you add the custom domain and bind a certificate, which can be a managed certificate or a certificate you upload or reference from Azure Key Vault. The certificate is associated with the app's ingress configuration, not with the container image or registry. This is where the platform terminates TLS before forwarding traffic to your container.

Exam trap

The trap here is conflating client-side certificate trust (certs inside the container) with platform-level inbound TLS termination, causing candidates to pick the container filesystem option.

How to eliminate wrong answers

Option B is wrong because Azure Container Registry webhooks are notification mechanisms for image push/delete events and have nothing to do with TLS certificates or ingress. Option C is wrong because placing certs in the container filesystem under /etc/ssl/certs only affects TLS the container initiates as a client; it does not configure the platform's inbound TLS termination for the custom domain. Option D is wrong because Container Apps does not expose or rely on an underlying ACI node pool for certificate configuration — that is a fabricated layer; Container Apps runs on a managed Kubernetes-based environment.

Practice this question →
99
Multi-Selecthard

You are deploying a containerized AI model to Azure Container Apps. The model requires a persistent volume to store intermediate results and a secret to access an external API. You need to configure the container app to meet these requirements. Which two actions should you perform? (Choose two.)

Select 2 answers
A.Mount an Azure Blob Storage container as a file system using the BlobFuse driver.
B.Use a Kubernetes PersistentVolumeClaim (PVC) to provide persistent storage.
C.Embed the API secret in the container image as a build argument.
D.Store the API secret as a container app secret and reference it in an environment variable.
E.Create an Azure Files share and mount it as a volume in the container app.
AnswersD, E

Azure Container Apps allows you to define secrets at the application level. These secrets can be referenced in environment variables, which the container can read at runtime. This securely provides the API secret without hardcoding it in the image or configuration files. It is the recommended approach for managing sensitive data.

Why this answer

To provide persistent storage, you should create an Azure Files share and mount it as a volume in the container app. For the secret, you should store it as a container app secret and reference it in an environment variable. These actions meet the requirements securely and using native Azure Container Apps features.

Exam trap

The trap here is assuming that Kubernetes-native constructs like PVCs or alternative storage drivers like BlobFuse are supported, when Azure Container Apps has its own abstractions for storage and secrets.

Practice this question →
100
MCQeasy

Which Azure feature allows you to scan images in your registry for vulnerabilities before deploying them to your production cluster?

A.Microsoft Defender for Containers.
B.Azure Monitor.
C.Azure Key Vault.
D.Azure Policy.
AnswerA

Microsoft Defender for Containers scans images stored in Azure Container Registry for known vulnerabilities, surfacing findings before deployment. This satisfies the stem's pre-deployment scanning requirement, unlike registry RBAC or geo-replication, which govern access and availability rather than vulnerability detection.

Why this answer

Microsoft Defender for Containers is the Azure service that provides vulnerability scanning for container images stored in Azure Container Registry (ACR) and other registries. It automatically scans images on push and continuously monitors for new vulnerabilities, giving you a security assessment before deployment. This aligns with the question's requirement to scan images in your registry for vulnerabilities.

Exam trap

AI-200 often tests the distinction between security scanning (Defender for Containers) and policy enforcement (Azure Policy) or monitoring (Azure Monitor), so candidates may incorrectly choose Azure Policy because it can block deployments, but it does not perform vulnerability scanning.

How to eliminate wrong answers

Option B is wrong because Azure Monitor is a monitoring and observability service that collects metrics and logs; it does not perform vulnerability scanning of container images. Option C is wrong because Azure Key Vault is used for securely storing and managing secrets, keys, and certificates; it has no image scanning capability. Option D is wrong because Azure Policy is used to enforce organizational standards and assess compliance at scale; while it can audit or deny deployments based on conditions, it does not scan images for vulnerabilities.

Practice this question →
101
MCQmedium

You are deploying an AI model container to Azure Container Apps. The container requires persistent storage to cache downloaded Hugging Face model weights across container restarts. Which storage type should you attach to the Container App?

A.Azure Managed Disks (Premium SSD) direct attach
B.Azure Blob Storage FUSE driver
C.Azure Files mount via Container Apps storage configuration
D.Ephemeral emptyDir volume
AnswerC

Azure Files mounts an SMB or NFS share into the container's filesystem, so cached Hugging Face weights persist outside the container lifecycle and survive restarts and revisions. This directly satisfies the persistent storage constraint, unlike ephemeral container-local disk or replica-scoped temporary storage.

Why this answer

Azure Container Apps supports mounting Azure Files shares as persistent volumes through the storage configuration at the environment or app level. Azure Files is the only fully managed, SMB/NFS-based shared file system that Container Apps can mount natively, and it persists independently of the container replica lifecycle, making it ideal for caching model weights across restarts.

Exam trap

AI-200 often tests whether candidates assume Container Apps supports the same volume types as AKS (Managed Disks, Blob FUSE) — in reality only Azure Files is natively mountable.

How to eliminate wrong answers

Option A is wrong because Azure Managed Disks cannot be directly attached to Container Apps — they are block devices designed for VMs and AKS, not the Container Apps sandbox. Option B is wrong because the Blob FUSE driver is a Linux FUSE client typically used inside AKS or VMs; Container Apps does not natively mount Blob Storage via FUSE as a volume. Option D is wrong because an emptyDir volume is ephemeral and tied to the pod/replica lifetime, so it is wiped on restart and cannot cache weights persistently.

Practice this question →
102
MCQeasy

You are deploying a custom PyTorch model container image to Azure Container Apps. The container needs to scale out based on HTTP concurrent requests. Which built-in scale rule type should you configure in Azure Container Apps?

A.azure-service-bus
B.cpu
C.tcp
D.http
AnswerD

The http scale rule scales replicas according to concurrent HTTP requests, which matches the stated trigger. Azure Container Apps evaluates this built-in rule against incoming request concurrency, adding or removing replicas to meet demand without custom KEDA configuration.

Why this answer

Azure Container Apps supports built-in KEDA-based scale rules, and the 'http' scale rule type scales based on concurrent HTTP requests. This is the correct choice for scaling a container that receives HTTP traffic and needs to handle concurrent requests.

Exam trap

AI-200 often tests whether candidates know the built-in scale rule types in Azure Container Apps — the trap is selecting 'cpu' because it's a common default, but the question specifically asks for scaling based on HTTP concurrent requests, which maps to the 'http' rule.

How to eliminate wrong answers

Option A is wrong because 'azure-service-bus' scales based on the number of messages in an Azure Service Bus queue or topic, not HTTP requests. Option B is wrong because 'cpu' scales based on CPU utilization percentage, which is a resource metric, not HTTP concurrency. Option C is wrong because 'tcp' scales based on concurrent TCP connections, which is a lower-level metric and not specific to HTTP request concurrency.

Practice this question →
103
MCQmedium

You are deploying an AI workload to Azure Container Apps. You need to ensure the container scales down to zero when there is no traffic. What should you configure?

A.Set maximum replicas to 0.
B.Enable the 'Always On' flag.
C.Set minimum replicas to 0.
D.Configure an external HTTP trigger.
AnswerC

Setting minimum replicas to zero permits the scale rule to reduce the revision to no running instances when traffic ceases, satisfying the scale-to-zero requirement. Container Apps then activates a replica on the next incoming request, so cold-start latency applies but idle compute cost is eliminated.

Why this answer

Azure Container Apps scales to zero when the minimum replica count is set to 0. This allows the platform to deprovision all replicas during periods of no traffic, eliminating compute cost, and scale back up when a request arrives (subject to the configured scale rules and HTTP ingress).

Exam trap

AI-200 often tests the min vs. max replica distinction, tricking candidates who pick 'maximum replicas to 0' or 'Always On' when the correct lever is minimum replicas.

How to eliminate wrong answers

Option A is wrong because maximum replicas defines the upper scaling bound; setting it to 0 would prevent any replicas from running and is not a valid or meaningful configuration for scale-to-zero. Option B is wrong because 'Always On' keeps at least one replica running, which is the opposite of scaling to zero. Option D is wrong because configuring an external HTTP trigger enables ingress and can drive scaling, but it does not by itself cause scale-to-zero — the minimum replica count must be 0.

Practice this question →
104
Multi-Selecteasy

Your organization requires that container images stored in Azure Container Registry (ACR) comply with security standards. Which TWO actions can you take to secure container images in ACR? (Choose two.)

Select 2 answers
A.Grant Contributor permissions to every external guest user
B.Store registry administrator credentials in public GitHub repositories for easy team access
C.Disable all network firewalls on the registry to allow unrestricted public pulling
D.Enable Microsoft Defender for Cloud vulnerability scanning for ACR registries
E.Enable content trust to ensure only signed container images are deployed
AnswersD, E

Microsoft Defender for Cloud scans ACR registries for vulnerabilities in pushed images, surfacing CVEs against your security baseline. Enabling it directly satisfies the requirement that stored container images comply with security standards, giving continuous assessment rather than build-time-only checks.

Why this answer

Option D is correct because enabling Microsoft Defender for Cloud's vulnerability scanning for ACR registries continuously scans images for known CVEs and provides remediation guidance, directly supporting image security compliance. Option E is correct because enabling content trust (Docker Content Trust) enforces image signing and verification, ensuring only trusted, signed images are pulled or deployed, which prevents tampered or unauthorized images from being used. Option A is wrong because granting Contributor permissions to every external guest user violates least-privilege and expands the attack surface rather than securing images.

Option B is wrong because storing registry administrator credentials in public GitHub repositories exposes secrets and enables unauthorized access. Option C is wrong because disabling network firewalls and allowing unrestricted public pulling removes network-level protections and increases exposure of the registry.

Exam trap

The trap is that candidates pick 'easy access' options (public GitHub, open firewalls, broad Contributor) thinking they improve collaboration, when the question asks for security controls — always favor least privilege, network isolation, and content integrity.

Practice this question →
105
Multi-Selecthard

You are designing a secure MLOps pipeline using Azure Container Registry. Which THREE practices should you implement to secure your AI container images?

Select 3 answers
A.Disable role-based access control (RBAC) on the registry to simplify management
B.Use managed identities instead of admin credentials for registry authentication
C.Sign container images using Notation before pushing to ACR
D.Enable Microsoft Defender for Cloud vulnerability scanning on the ACR registry
E.Enable anonymous pull access for all public developers
AnswersB, C, D

Managed identities let the pipeline authenticate to Azure Container Registry without stored admin passwords, eliminating long-lived credentials that could be leaked. This directly satisfies the stem's constraint of securing AI container images within the MLOps pipeline.

Why this answer

Option B is correct because managed identities let Azure services (e.g., AKS, Azure ML) authenticate to ACR without storing admin username/password secrets, eliminating credential leakage and enabling least-privilege RBAC assignments. Option C is correct because signing images with Notation (Notary Project) and verifying signatures at deploy time ensures image integrity and provenance, preventing tampered or unauthorized images from running. Option D is correct because Microsoft Defender for Cloud's container registry scanning continuously detects OS and language-level CVEs in pushed images, so vulnerable images can be remediated before deployment.

Option A is wrong because disabling RBAC removes fine-grained access control and weakens registry security rather than simplifying it safely. Option E is wrong because anonymous pull access exposes images to anyone, violating the principle of least privilege and risking IP theft or supply-chain abuse.

Exam trap

AI-200 often tests whether candidates confuse 'simplify management' with 'improve security' — disabling RBAC or enabling anonymous pull sounds convenient but is a security anti-pattern.

Practice this question →
← PreviousPage 2 of 2 · 105 questions total

Ready to test yourself?

Try a timed practice session using only Containerized Ai Workloads questions.

Start 20-question session