AI-200: Develop Containerized Solutions on Azure

Topic snapshot

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Develop Containerized Solutions on Azure

A team deploys a new Azure Container Apps revision for a Python API. After traffic is shifted to the latest revision, users receive 503 responses.

Flow and evidence:

Image pushed -> revision chat-api--v12 created -> 100% traffic to latest

Revision chat-api--v12
Running status: Degraded
Ready replicas: 0/1
Scale: min=1 max=5
Ingress target port: 8080

System logs:
Image pull succeeded
Started container chat-api
Startup probe failed: connect tcp :8080 refused

App logs:
Uvicorn running on http://0.0.0.0:8000

Which failure point is indicated by the visible evidence?

Options:

• A. External ingress is disabled for the Container App.

• B. The image cannot be pulled from Azure Container Registry.

• C. KEDA cannot scale the app because minimum replicas is zero.

• D. Ingress and startup probe target 8080 while the app listens on 8000.

Best answer: D

Explanation: Azure Container Apps revision diagnosis should follow the deployment path: image pull, container start, readiness/startup checks, then ingress routing. Here, the image pull succeeded and the container process started, so the failure is later in activation. The revision is degraded with 0 ready replicas, and the startup probe fails when connecting to port 8080. The app log shows the API is listening on port 8000. Align the Container Apps ingress target port and probe configuration with the container’s actual listener, or configure the app to listen on the expected port. The key signal is the mismatch between the health check target and the process listener.

• Image pull issue fails because the system log explicitly shows the image pull succeeded and the container started.
• Scale rule issue fails because the scale setting shows a minimum replica of 1, and the failure is a refused probe connection.
• Disabled ingress fails because the evidence shows an ingress target port; the problem is the wrong port, not missing ingress.

Question 2

Topic: Develop Containerized Solutions on Azure

A Python RAG API is deployed to Azure Container Apps. A new revision never receives traffic because it remains not ready. The deployment path and startup logs show the following. Which failure point should you address first?

ACR pull: myacr.azurecr.io/rag-api:1.8.2
Pull status: succeeded
Container: created
Container: started
stdout: loading application settings
stderr: KeyError: 'COSMOS_ENDPOINT'
Exit code: 1
Readiness probe: connection refused

Options:

• A. Configure the missing COSMOS_ENDPOINT runtime setting.

• B. Fix the readiness probe target path.

• C. Increase the minimum replica count.

• D. Update the ACR credentials for the revision.

Best answer: A

Explanation: Container startup logs should be read in sequence. An image pull failure occurs before the container is created or started, but this flow shows the ACR pull succeeded. The application then starts, loads settings, raises KeyError: 'COSMOS_ENDPOINT', and exits with code 1. The readiness probe reports connection refused only after the process has stopped, so the probe result is a symptom rather than the root failure. The actionable issue is missing runtime configuration for the revision, such as an environment variable or secret reference.

• ACR credentials fail because the log explicitly shows the image pull succeeded.
• Readiness probe is only reporting that no process is listening after the app exits.
• Replica count does not fix a deterministic startup failure; each replica would hit the same missing setting.

Question 3

Topic: Develop Containerized Solutions on Azure

A team deployed a Python RAG API as a custom container to Azure App Service. The optimized release met the latency target in testing, but production p95 latency remains high.

Exhibit: Deployment evidence

Intended release:
Image: contoso.azurecr.io/rag-api:20260515.3
CACHE_TTL_SECONDS: 300

App Service diagnostics:
Configured image: contoso.azurecr.io/rag-api:latest
Resolved digest: sha256:0b7d...
CACHE_TTL_SECONDS: 0
Startup log: response cache disabled

Which action should the developer take first to improve efficiency without weakening deployment reliability?

Options:

• A. Scale up the App Service plan before changing configuration.

• B. Enable Always On to reduce container cold-start latency.

• C. Keep latest and bake the cache value into the image.

• D. Pin the intended image tag and set CACHE_TTL_SECONDS=300.

Best answer: D

Explanation: App Service custom container evidence should be checked against the intended release: the configured image, resolved image digest or tag, startup logs, and app settings exposed as environment variables. In this case, production is not using the intended immutable image tag and CACHE_TTL_SECONDS is 0, which the log confirms disables the response cache. Pinning the tested image tag and setting the App Service app setting to 300 directly applies the known performance change while avoiding the deployment risk of a mutable latest tag. Scaling resources would cost more without fixing the mismatch.

• Scaling first misses the visible configuration mismatch and may increase cost without enabling the tested optimization.
• Using latest weakens release reliability because the running digest may change without an explicit versioned deployment.
• Always On can help startup behavior, but the evidence points to disabled caching during normal request processing.

Question 4

Topic: Develop Containerized Solutions on Azure

A team builds a container image in Azure Container Registry and deploys it to Azure Container Apps. The registry admin account is disabled, and security policy forbids storing registry passwords or service principal secrets in app settings or the CI/CD pipeline. New revisions must pull the private image during startup. Which implementation should you use?

Options:

• A. Run docker login in the pipeline before creating each revision.

• B. Enable the ACR admin account and store its password as an app secret.

• C. Make the repository public and restrict access with image tags.

• D. Grant a managed identity AcrPull and configure the registry to use that identity.

Best answer: D

Explanation: For private images in Azure Container Registry, the hosting service must authenticate when it pulls the image at runtime or revision startup. Azure Container Apps supports using a managed identity for registry access. Assign the identity the AcrPull role scoped to the registry, then configure the container app registry settings to use that identity for the ACR login server. This satisfies the need to pull private images without enabling the registry admin account or storing long-lived credentials in configuration or deployment automation.

A pipeline login helps the build or push step, but it does not authenticate the Container Apps runtime when a new revision pulls the image.

• Admin credentials violate the stated policy because they require storing a registry password.
• Pipeline-only login does not give the Container Apps runtime permission to pull the image later.
• Public repository weakens registry access control, and tags are not an authentication boundary.

Question 5

Topic: Develop Containerized Solutions on Azure

A Python AI back-end runs in Azure Container Apps. Chat requests are returning HTTP 500 because the app secret reference for Azure Cosmos DB for NoSQL was incorrect. You fix the secret reference and route traffic to a new active revision. The app emits OpenTelemetry request and dependency telemetry to Log Analytics. Which monitoring signal best confirms recovery?

Options:

• A. The replica restart count has stopped increasing

• B. The container image pull from Azure Container Registry succeeded

• C. The new Container Apps revision state is Active

• D. End-to-end traces with 2xx requests and successful Cosmos DB spans

Best answer: D

Explanation: Recovery should be confirmed with a workload-level signal that exercises the remediated failure path. Here, the incident was not merely that the container failed to start; requests failed because the app could not use its Cosmos DB secret. An end-to-end OpenTelemetry signal showing successful HTTP responses and successful Cosmos DB dependency spans proves that the new revision is receiving traffic, loading the corrected configuration, and reaching the data service. Platform signals such as revision state, image pull, or restart count are useful supporting evidence, but they can be healthy while the application still returns 500s.

• Active revision only confirms the revision is deployed and eligible for traffic, not that the Cosmos DB path works.
• Image pull success validates registry access, not runtime configuration or data-service connectivity.
• Stable restarts can show the process is not crashing, but a running app can still fail requests.

Question 6

Topic: Develop Containerized Solutions on Azure

A team deploys a new Python API revision to Azure Container Apps and routes 100% of traffic to it. Users receive HTTP 502 responses. The container logs show:

INFO: Uvicorn running on http://0.0.0.0:8000
ERROR: Ingress failed to connect to container on target port 80

The revision has external ingress enabled with targetPort set to 80. What should you do next?

Options:

• A. Increase the revision replica count.

• B. Rotate the Azure Container Registry credentials.

• C. Add a private DNS zone for the app.

• D. Update ingress targetPort to 8000.

Best answer: D

Explanation: The evidence points to a port mismatch, not a scaling, image-pull, or DNS problem. Azure Container Apps ingress forwards requests to the configured targetPort. If the container process listens on 0.0.0.0:8000 but ingress targets 80, the platform cannot connect to the app and clients can receive 502 responses. The next step is to align the Container Apps ingress port with the application listener, then validate the new revision. Scaling should come after basic connectivity is correct.

• Scaling replicas does not fix a listener-port mismatch; more replicas would still be unreachable on port 80.
• Rotating registry credentials targets image-pull authentication, but this container is already running and logging.
• Adding DNS addresses name resolution, while the logs show ingress reaching the revision but using the wrong port.

Question 7

Topic: Develop Containerized Solutions on Azure

A Python worker in Azure Container Apps processes embedding-write jobs from an Azure Service Bus queue by using an existing KEDA Service Bus scale rule. The queue is empty for hours overnight, and a cold start of up to 45 seconds is acceptable. During bursts, the app should use as much safe concurrency as possible without exceeding the Azure Database for PostgreSQL limit of 24 write connections. Each replica opens 4 write connections. Which TWO scale settings should you choose? Select TWO.

Options:

• A. Set maxReplicas to 3.

• B. Set maxReplicas to 12.

• C. Set minReplicas to 1.

• D. Replace the Service Bus rule with CPU scaling.

• E. Set maxReplicas to 6.

• F. Set minReplicas to 0.

Correct answers: E and F

Explanation: Azure Container Apps uses KEDA scale rules to add replicas for event-driven workloads, while minReplicas controls idle cost and maxReplicas caps fan-out. Because this worker has long idle periods and can tolerate a cold start, minReplicas should be 0. The downstream PostgreSQL service is the limiting resource during bursts, so the replica cap should be based on connection capacity: 24 allowed write connections divided by 4 connections per replica equals 6 replicas. This keeps the worker responsive to queued messages without letting scale-out overload the database.

• Keeping one warm replica reduces cold starts but violates the idle-cost goal when a 45-second cold start is acceptable.
• Allowing 12 replicas could open 48 write connections, exceeding the PostgreSQL limit.
• CPU-only scaling reacts after containers are busy instead of scaling directly from Service Bus queue depth.
• Capping at three replicas protects the database but fails to use the available safe concurrency during bursts.

Question 8

Topic: Develop Containerized Solutions on Azure

A team uses an ACR Task to build a container image for an Azure Container Apps deployment. The deployment reports manifest unknown for the image tag it is configured to pull.

Build output excerpt:

Run status: Succeeded
[build] Successfully built sha256:9b7a21
[build] Successfully tagged contosoacr.azurecr.io/rag-api:20260515.4
[push] Pushed contosoacr.azurecr.io/rag-api:20260515.4
[push] digest: sha256:6f31a9...

Deployment requested image:
contosoacr.azurecr.io/rag-api:latest

Which conclusion best follows from the evidence?

Options:

• A. The task pushed the image to a different registry.

• B. The Docker build failed before an image was created.

• C. The task succeeded, but the deployment references an unpushed tag.

• D. The Container Apps identity cannot authenticate to ACR.

Best answer: C

Explanation: The ACR Task output shows a complete successful image lifecycle: the run status is Succeeded, the Docker build produced an image ID, the image was tagged as contosoacr.azurecr.io/rag-api:20260515.4, and that exact tag was pushed with a digest. The deployment failure is for rag-api:latest, which is not shown as a tag produced or pushed by this task run. The next practical fix is to deploy the pushed version tag or update the task to also tag and push latest if that is the intended release tag. The evidence does not indicate a build failure, registry mismatch, or authentication problem.

• Build failure is contradicted by the successful build ID and succeeded run status.
• Wrong registry is not supported because both the pushed image and requested image use contosoacr.azurecr.io.
• Authentication failure is not evidenced; the visible error is about a missing manifest for the requested tag.

Question 9

Topic: Develop Containerized Solutions on Azure

An AI inference API runs in Azure Container Apps. A team wants only a canary revision to send platform logs to a separate Log Analytics workspace. The pipeline changes only the revision template and shifts 10% of traffic to the canary.

Deployment flow:

Container Apps environment: cae-ai-prod
Environment log workspace: law-prod
No environment diagnostic setting to law-canary

Revision rag-api--001: image v1, traffic 90%
Revision rag-api--002: image v2, traffic 10%
Attempted canary change in revision template: workspace=law-canary
Observed v2 logs: law-prod

Which statement identifies the failure point in the flow?

Options:

• A. A KEDA scale rule selects the log workspace.

• B. A revision environment variable selects the log workspace.

• C. Traffic splitting delays canary logs until 100% traffic.

• D. The log workspace is shared environment configuration.

Best answer: D

Explanation: Azure Container Apps separates managed environment settings from app revision settings. The environment provides shared infrastructure boundaries and integrations, such as the logging destination and network configuration. A revision captures a version of the app runtime template, such as the container image, environment variables, resource settings, and scaling behavior. In this flow, requests can reach rag-api--002, but its platform logs still go to law-prod because that workspace is attached to cae-ai-prod. Traffic split controls request distribution, not the monitoring destination. To isolate platform logging for a canary, use an environment-level monitoring design, not a per-revision override.

• Traffic split misconception fails because traffic percentages choose revisions for requests; they do not choose the Log Analytics workspace.
• Environment variable misconception fails because runtime variables do not reconfigure Container Apps platform log routing.
• KEDA logging assumption fails because scale rules affect replica count, not the telemetry destination.

Question 10

Topic: Develop Containerized Solutions on Azure

An AKS workload runs a Python API for an AI feature. For the next release, you must update the manifests so the pods use image contoso.azurecr.io/rag-api:1.4.0, set nonsecret environment variable LOG_LEVEL=info, read AZURE_OPENAI_KEY from an existing Kubernetes Secret, and keep the API reachable only by other pods in the cluster. Which manifest change best satisfies these controls?

Options:

• A. Update the Deployment image, use secretKeyRef, and change the Service to LoadBalancer.

• B. Keep the current image, use secretKeyRef, and keep the Service as ClusterIP.

• C. Update the Deployment image, use literal LOG_LEVEL, use secretKeyRef, and keep ClusterIP.

• D. Update the Deployment image, store both variables in a ConfigMap, and keep ClusterIP.

Best answer: C

Explanation: For an AKS workload, image version and environment variables belong in the Deployment pod template, while service reachability is controlled by the Service manifest. A nonsecret setting such as LOG_LEVEL can be defined as a normal environment variable. A sensitive value such as AZURE_OPENAI_KEY should be referenced from a Kubernetes Secret with secretKeyRef so it is injected at runtime instead of being placed in plain text in application configuration. Keeping the Service type as ClusterIP preserves the requirement that only other pods in the cluster can reach the API. Changing exposure or mishandling the secret would weaken the stated controls.

• Storing the key in a ConfigMap treats sensitive data as ordinary configuration and fails the secret-handling requirement.
• Changing the Service to LoadBalancer exposes the workload beyond the in-cluster access requirement.
• Keeping the current image tag blocks the requested release even if the secret and service exposure are handled correctly.

Continue with full practice

Use the AI-200 Practice Test page for the full IT Mastery practice bank, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try AI-200 on Web View AI-200 Practice Test

Related focused pages

• Free AI-200 Full-Length Practice Exam
• Develop AI Solutions by Using Azure Data Management Services
• Connect to and Consume Azure Services
• Secure, Monitor, and Troubleshoot Azure Solutions

Free review resource

Read the AI-200 Cheat Sheet for compact concept review before returning to timed practice.