SaveMyCert
Log in
5 of 5 free questions left today·for 10 a day
AI-200 · Domain 1

Develop containerized solutions on Azure practice questions

Develop containerized solutions on Azure is worth 24% of the AI-200 exam — the 2nd-heaviest of the 4 domains. Building and storing images with Azure Container Registry and ACR Tasks, hosting containers on App Service, and running orchestrated workloads on Azure Container Apps (revisions, KEDA scaling) and AKS (manifests, logs, connectivity). Official weighting 20–25%. 6 fully worked examples are further down this page, answers included.

Exam weight
24%
the 2nd-heaviest of the 4 domains
Questions
96
across 2 topics
Free, no account
5/day
a free account allows 10 a day
Explanations
Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across 1 of 4 domains, in Learn mode.

Review what you missed

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

6 sample Develop containerized solutions on Azure questions, fully explained

Questions from the AI-200 bank mapped to domain 1, with the answer key and the reasoning behind every option. None of them repeat the examples on the main AI-200 practice page.

Question 1Develop containerized solutions on Azure

A team deploys its API by referencing myapp:latest. After a scale-out, new instances started running a build that was pushed an hour earlier and never tested, while older instances kept the tested build. The team wants every instance to run exactly the build that passed testing and keep releasing several times a day. What should the team change?

Choose one.

  • a
    Keep deploying latest and lock it with write-enabled set to false after each build

    Locking latest would stop the next release from being pushed under that tag, and unlocking it reopens the drift.

  • b
    Deploy a stable version tag, such as myapp:1.4, that each minor build updates

    Stable tags are meant to move with patches, so instances that pull at different times can still get different builds.

  • c
    Tag every build with a unique tag, such as the build ID, and deploy that tag Correct

    A unique tag is written once and never reassigned, so any instance that pulls it later gets the same tested image.

  • d
    Add a geo-replica so that every instance pulls each build from the same replica

    Replication changes where the image is pulled from, not which build a moving tag points to.

The concept

Stable tags move to new builds; unique tags identify one build forever.

Why that’s the answer

The symptom comes from a stable tag: latest was reassigned to a newer push, so instances that pulled after the push got the untested build. Deploying a unique tag per build (build ID, commit SHA or date stamp) makes every pull deterministic while new releases simply get new tags. Locking latest blocks releases, and a version tag such as 1.4 is still a stable tag that is expected to be reassigned.

How to reason it out
  1. Recognise the drift: instances pulling the same tag at different times got different images.
  2. Ask whether the tag can be reassigned; latest and 1.4 both can.
  3. Deploy a tag that is written once per build.

Exam tip: Deploy unique tags; keep stable tags for base images and humans.

AI-200 Container Hosting: Azure Container Registry, ACR Tasks and App Service Containers — the lesson that teaches this.

Question 2Develop containerized solutions on Azure

An auditor requires that a production release can be redeployed months later and run exactly the same image bytes that were approved. The pipeline pushes to an Azure container registry, and other teams can push new images to the same repository. Which image references meet the requirement? (Select TWO.)

Choose TWO.

  • a
    A unique per-build tag that is locked with write-enabled set to false Correct

    The tag is never reused by the pipeline, and the lock stops anyone overwriting or deleting it, so it keeps pointing at the approved image.

  • b
    A stable version tag, such as orders:2.1, kept in a geo-replicated registry

    Replication doesn't stop the 2.1 tag from being moved to a newer push by any team with write access.

  • c
    A manifest digest reference, such as orders@sha256:<digest> Correct

    A digest is computed from the image content, so it can only ever resolve to those exact bytes.

  • d
    A stable version tag protected with delete-enabled set to false

    Delete protection still allows the tag to be overwritten with a new image, so the reference can drift.

  • e
    The latest tag with the registry admin user disabled

    Disabling the admin user changes how clients authenticate; anyone with push rights can still move latest.

The concept

Reproducible deployments need a reference that can't move: a digest, or a unique tag that is locked.

Why that’s the answer

A digest is content-addressed and can't point at anything else. A unique tag is only safe when nobody can rewrite it, which is what write-enabled false guarantees. The tempting near-twin is delete-enabled false: it blocks deletion but still lets a push overwrite the tag. Replication and authentication settings don't affect what a tag points to.

How to reason it out
  1. Ask what could make the reference resolve to different bytes later.
  2. Digests can't change; tags can unless writes are locked.
  3. Distinguish write-enabled false (no overwrite or delete) from delete-enabled false (no delete only).

Exam tip: Immutable reference = digest, or a unique tag with write-enabled false.

AI-200 Container Hosting: Azure Container Registry, ACR Tasks and App Service Containers — the lesson that teaches this.

Question 3Develop containerized solutions on Azure

A release manager must make sure that the image payments:3.2.0 in the registry contosoacr can never be overwritten or deleted. Developers must still be able to push and delete other tags in the payments repository. Which command should the release manager run?

Choose one.

  • a
    az acr repository update --name contosoacr --image payments:3.2.0 --write-enabled false Correct

    Setting write-enabled to false on the one tag blocks both overwrites and deletes for that image and leaves the rest of the repository open.

  • b
    az acr repository update --name contosoacr --image payments:3.2.0 --delete-enabled false

    Delete protection alone still allows a push to overwrite payments:3.2.0 with a different image.

  • c
    az acr repository update --name contosoacr --repository payments --write-enabled false

    Locking the repository locks every image in it, which stops developers pushing other tags.

  • d
    az lock create --name keep --lock-type CanNotDelete --resource contosoacr --resource-type Microsoft.ContainerRegistry/registries

    A resource lock protects the registry resource from management operations; it doesn't stop image pushes or deletes inside it.

The concept

Image locking uses az acr repository update attributes on a tag, digest or repository.

Why that’s the answer

ACR image locks are attributes set with az acr repository update. write-enabled false on a single tag makes it immutable: it can't be overwritten, and a write lock also blocks deletion. Applying it to the repository is too broad, delete-enabled false alone is too weak, and an Azure resource lock (az lock) acts only on management-plane operations such as deleting the registry.

How to reason it out
  1. Find the scope: one tag, not the whole repository.
  2. Find the protection: no overwrite and no delete.
  3. Pick write-enabled false on --image, and rule out resource locks, which don't cover repository data.

Exam tip: Freeze one image: az acr repository update --image repo:tag --write-enabled false.

AI-200 Container Hosting: Azure Container Registry, ACR Tasks and App Service Containers — the lesson that teaches this.

Question 4Develop containerized solutions on Azure

In a registry, the repository base-images must never be deleted as a whole. Inside it, the tag ubuntu-patched:22.04 is refreshed every week with new patches and must never be deleted, while other tags in the repository can still be updated or removed. Which commands meet the requirements? (Select TWO.)

Choose TWO.

  • a
    az acr repository update --name reg --image base-images/ubuntu-patched:22.04 --write-enabled false

    A write lock makes the tag immutable, which blocks the weekly patched push.

  • b
    az acr repository update --name reg --repository base-images --delete-enabled false --write-enabled true Correct

    This protects the repository itself from deletion while individual images in it can still be updated or deleted.

  • c
    az acr repository update --name reg --repository base-images --write-enabled false

    A write lock on the repository blocks updates to every image in it, including the weekly refresh.

  • d
    az lock create --name keep --lock-type CanNotDelete --resource reg --resource-type Microsoft.ContainerRegistry/registries

    A resource lock on the registry doesn't stop repositories or images being deleted, because those are data operations.

  • e
    az acr repository update --name reg --image base-images/ubuntu-patched:22.04 --delete-enabled false --write-enabled true Correct

    Delete protection on the tag stops it being removed while still allowing the weekly push to overwrite it.

The concept

Repository-level and image-level lock attributes are independent, and delete-enabled differs from write-enabled.

Why that’s the answer

Two separate protections are needed. A repository with delete-enabled false can't be deleted, but its individual images can still be updated or deleted, so the tag needs its own delete-enabled false. Both keep write-enabled true because the tag is refreshed weekly. A write lock at either level blocks that refresh, and a resource lock covers only management operations on the registry.

How to reason it out
  1. List the three requirements: repository not deletable, tag not deletable, tag still writable.
  2. Recall that a repository's delete protection doesn't extend to the images inside it.
  3. Use delete-enabled false with write-enabled true at both levels; avoid write locks.

Exam tip: Delete-protect the repository and the tag separately; write-enabled false would also block updates.

AI-200 Container Hosting: Azure Container Registry, ACR Tasks and App Service Containers — the lesson that teaches this.

Question 5Develop containerized solutions on Azure

A pipeline agent has the Azure CLI but no Docker engine. It must copy the public image nginx:1.27 from Docker Hub into an Azure container registry and keep the image's original manifest digest. What should the pipeline run?

Choose one.

  • a
    az acr import --name reg --source docker.io/library/nginx:1.27 --image nginx:1.27 Correct

    Import copies the image registry-to-registry inside Azure, needs no Docker engine and keeps the original manifest and digest.

  • b
    az acr build --registry reg --image nginx:1.27 with a Dockerfile containing FROM nginx:1.27

    This builds a new image in ACR Tasks; the result is a new manifest with a different digest, not a copy.

  • c
    docker pull nginx:1.27, docker tag to reg.azurecr.io, then docker push after az acr login

    This copies the image but needs a Docker engine, which the agent doesn't have.

  • d
    az acr task create --registry reg --name copy --cmd docker.io/library/nginx:1.27 --context /dev/null

    A cmd step runs the image as a container; it doesn't store a copy of the image in the registry.

The concept

az acr import copies images into ACR from public or other registries without a local Docker engine.

Why that’s the answer

Import is a server-side copy: Azure pulls the image from the source registry and writes it into the target registry, preserving the manifest and its digest. It needs only the Azure CLI. Building FROM the image produces a new image with a new digest, docker push needs a local engine, and a task cmd step only runs the container.

How to reason it out
  1. Note the constraints: no Docker engine, keep the digest.
  2. Rule out anything that rebuilds (new digest) or needs docker.
  3. Choose the server-side copy command.

Exam tip: Copy, don't rebuild: az acr import.

AI-200 Container Hosting: Azure Container Registry, ACR Tasks and App Service Containers — the lesson that teaches this.

Question 6Develop containerized solutions on Azure

Build pipelines pull python:3.12-slim from Docker Hub many times an hour and are hitting Docker Hub pull rate limits. The developer wants the Standard-tier Azure container registry to fetch the image from Docker Hub on the first request and serve its stored copy afterwards, without writing or scheduling any copy jobs. What should the developer configure?

Choose one.

  • a
    An ACR task with a nightly timer trigger that runs az acr import for the image

    A scheduled import would avoid rate limits, but it's exactly the copy job the developer wants to avoid writing and maintaining.

  • b
    A connected registry that synchronizes the python repository from Docker Hub on demand

    A connected registry is an on-premises or edge replica that syncs from a parent Azure registry, not from Docker Hub, and it needs Premium.

  • c
    A cache rule with a Docker Hub credential set for docker.io/library/python Correct

    A cache rule pulls the upstream image on first request and serves the cached copy afterwards; it works in every tier, and Docker Hub sources need a credential set.

  • d
    A geo-replica of the registry in the same region as the build agents that pull python

    Geo-replication needs Premium and replicates content already in the registry; it doesn't fetch from Docker Hub.

The concept

Artifact cache rules make ACR a pull-through cache for upstream registries such as Docker Hub.

Why that’s the answer

The requirement describes pull-through caching: fetch upstream on the first request, then serve locally. ACR's artifact cache does exactly that through a cache rule that maps an upstream repository to a repository in the registry. It's available in the Basic, Standard and Premium tiers, and a Docker Hub upstream supports authenticated pulls only, so the rule uses a credential set whose username and token are stored as Key Vault secrets. A scheduled import also solves the rate limit but adds the copy job the developer ruled out, and the other options either need Premium or don't pull from Docker Hub.

How to reason it out
  1. Identify the behaviour: fetch on demand, then serve the stored copy.
  2. Note the constraints: Standard tier, no scheduled copy jobs.
  3. Match it to a cache rule, and give a Docker Hub source a credential set.

Exam tip: Pull-through cache for Docker Hub images: an ACR cache rule with a credential set.

AI-200 Container Hosting: Azure Container Registry, ACR Tasks and App Service Containers — the lesson that teaches this.

What AI-200 domain 1 tests, topic by topic

The official exam guide breaks Develop containerized solutions on Azure into 2 topics. The question bank follows the same split, so a weak topic shows up as a cluster of misses you can go back and read.

Published AI-200 practice questions per topic in Develop containerized solutions on Azure
TopicWhat it coversQuestions
Implement container application hostingSkills outline section (AI-200, study guide dated April 15, 2026). Build, store, version, and manage container images by using Azure Container Registry; Build and run images by using Azure Container Registry Tasks; Deploy containers to Azure App Service, including configuring App Service to supply environment variables and secrets.48
Implement container-orchestrated solutionsSkills outline section (AI-200, study guide dated April 15, 2026). Deploy applications to Azure Container Apps, including environment configuration and revision management; Implement event-driven scaling by using Kubernetes Event-driven Autoscaling (KEDA) in Container Apps; Deploy and manage applications to Azure Kubernetes Service (AKS) by using manifest files; Monitor and troubleshoot solutions on AKS and Container Apps by inspecting logs, events, and end-to-end connectivity.48
Total96

Revise Develop containerized solutions on Azure before you drill it

AI-200 Container Hosting: Azure Container Registry, ACR Tasks and App Service ContainersQuestions on this topic are scenarios with one deciding requirement, such as no local Docker engine, keep the original digest, least privilege, no stored passwords, a Standard tier registry, without rebuilding the image, or without changing configuration. Many show a CLI command, a cron expression, a task YAML file or a Key Vault reference and ask which variant meets the requirement, so the near-twins matter: write-enabled versus delete-enabled, image versus repository scope, $Registry versus $RegistryName, client ID versus resource ID, vnetImagePullEnabled versus vnetRouteAllEnabled, and app settings versus connection strings.AI-200 Container Apps and AKS: Revisions, KEDA Scaling, Manifests and TroubleshootingQuestions on this topic are scenarios with one deciding requirement: cost nothing while idle, no stored credentials, never reachable from the internet, a URL that stays the same across releases, roll back within seconds, least administrative effort. Many put a manifest, a scale-rule definition, a CLI command or a KQL query in the stem and ask what to change or which line or table completes it, so you need the real names of settings, commands and log tables rather than a general idea of them. Others describe a symptom on AKS or Container Apps and ask for the fix or the next diagnostic step. Every option is usually a real feature, so read for the constraint that rules each one out. Some items ask you to select two.

Other AI-200 domains

Domain 2: Develop AI solutions by using Azure data management services28% of the exam · 112 questionsDomain 3: Connect to and consume Azure services24% of the exam · 96 questionsDomain 4: Secure, monitor, and troubleshoot Azure solutions24% of the exam · 96 questionsAll AI-200 practice questionsMixed sessions across all 4 domains — the way the real exam interleaves them.

Develop containerized solutions on Azure: your questions

Develop containerized solutions on Azure is domain 1 of the AI-200 exam guide and carries 24% of the scored content — the 2nd-heaviest of the 4 domains. On a 50-question paper that works out to roughly 12 questions, though Microsoft Azure does not publish an exact per-domain count and individual exam forms vary.

Source

The domain weight and topic list on this page come from the official AI-200 exam guide.