AI-200 · Domain 1: Develop containerized solutions on Azure · 22% of the exam
Task 1.1: Implement container application hosting
Building, storing, versioning and cleaning up images in Azure Container Registry, building and running them with ACR Tasks, and running containers on App Service with environment variables and secrets supplied by the platform.
Study it
Azure Container Registry: tiers, tags, locks, retention and access
Try each one before opening the answer. Every option is explained, with the Microsoft documentation page that proves it.
Question 1 · choose 1
Your team keeps its images in an Azure Container Registry on the Basic tier. A new Container Apps deployment in a second region must pull images from a replica in that region, and security now requires the registry to be reachable only through private endpoints. What do you change?
AMove the registry to the Standard tier, then add a geo-replica and private endpoints
BMove the registry to the Premium tier, then add a geo-replica and private endpoints
CTurn on zone redundancy for the Basic registry and keep pulling across regions
DCreate a second Basic registry in the new region and copy images to it with an ACR task
Show the answer and why
AMove the registry to the Standard tier, then add a geo-replica and private endpoints
Incorrect
Standard adds storage and throughput over Basic, but geo-replication and private endpoints still aren't available on it.
BMove the registry to the Premium tier, then add a geo-replica and private endpoints
Correct
Geo-replication and private link with private endpoints are Premium-only features; Basic and Standard show both as not available.
CTurn on zone redundancy for the Basic registry and keep pulling across regions
Incorrect
Zone redundancy is already on by default for every tier in supported regions; it spreads one regional registry across zones, not into a second region, and adds no private endpoints.
DCreate a second Basic registry in the new region and copy images to it with an ACR task
Incorrect
A second registry is a separate registry to manage, not a replica, and a Basic registry still can't be restricted to private endpoints.
Basic, Standard and Premium share the same data plane APIs, but geo-replication (one registry served from several regions) and private link with private endpoints exist only on Premium. Upgrading the tier in place keeps the registry name and its images.
A pipeline builds an image every time code is committed, and an ACR task also rebuilds it whenever its base image is patched. Deployed images must carry a tag that is never reused, stays unique even when a base-image rebuild runs on the same source code, and lets an operator find the pipeline run, its logs and artifacts from the tag alone. Which tagging scheme fits?
AThe Git commit hash of the source that was built
BThe build ID of the run that produced the image
CThe image manifest digest
DA stable major.minor tag such as 2.4
Show the answer and why
AThe Git commit hash of the source that was built
Incorrect
A base-image rebuild starts from the same commit as the previous build, so the commit hash would be reused for different image content.
BThe build ID of the run that produced the image
Correct
A build ID is incremental and unique per run, including base-image rebuilds, and it maps straight back to the build and its logs.
CThe image manifest digest
Incorrect
The digest is unique, but it's long, hard to read and has no link to the build system that produced the image.
DA stable major.minor tag such as 2.4
Incorrect
Stable tags are reused and keep receiving updates, which is why they're recommended for base images rather than for deployments.
Microsoft recommends unique tags for deployments so a restart or a scale-out never pulls different content. Of the unique schemes, a build ID is incremental and correlates to the run that produced the image; a commit hash is only semi-stable once base-image updates trigger builds.
An ACR task builds your application image from a Dockerfile whose FROM line points at a public Docker Hub image. When the base image is patched, the rebuild starts anywhere from 10 minutes to an hour later. You want the rebuild to start as soon as the patched base is available, without running builds when nothing changed. What should you do?
AAdd a timer trigger with the cron expression "* * * * *" to the task
BRun az acr task update with --base-image-trigger-enabled True on the existing task
CBuild FROM a copy of the base image kept in an Azure container registry
DMove the base image into the build stage of a multi-stage Dockerfile
Show the answer and why
AAdd a timer trigger with the cron expression "* * * * *" to the task
Incorrect
A timer runs the task every minute whether or not the base image changed, which wastes builds and doesn't track the dependency.
BRun az acr task update with --base-image-trigger-enabled True on the existing task
Incorrect
Base-image triggers are already on by default for tasks created with az acr task create; the delay comes from where the base lives.
CBuild FROM a copy of the base image kept in an Azure container registry
Correct
For base images in an Azure container registry, ACR Tasks triggers the dependent run immediately when the base image is updated.
DMove the base image into the build stage of a multi-stage Dockerfile
Incorrect
ACR Tasks tracks base images of the runtime image only, not of intermediate build stages, so this would stop tracking the base.
ACR Tasks discovers base image dependencies at build time. For public bases in Docker Hub or MCR it polls at a random interval of 10 to 60 minutes; for bases in an Azure container registry, in any region, it triggers right away. Microsoft also recommends keeping copies of public base images in a private registry.
You deploy a Linux custom container to Azure App Service. The image is in an Azure container registry that uses the RBAC Registry Permissions mode, the app has a system-assigned managed identity, and no registry password may be stored anywhere. The Python app inside the container listens on port 8000. Which two configurations do you need? (Choose TWO.)
AEnable the registry admin user and store its password in DOCKER_REGISTRY_SERVER_PASSWORD
BGrant the app's identity AcrPull on the registry and set acrUseManagedIdentityCreds to true in the site configuration
CSet vnetImagePullEnabled to true on the app
DSet the WEBSITES_PORT app setting to 8000
ESet WEBSITES_ENABLE_APP_SERVICE_STORAGE to true
Show the answer and why
AEnable the registry admin user and store its password in DOCKER_REGISTRY_SERVER_PASSWORD
Incorrect
The admin user is a shared credential with full push and pull access, and storing its password breaks the requirement.
BGrant the app's identity AcrPull on the registry and set acrUseManagedIdentityCreds to true in the site configuration
Correct
With the role in place, this setting makes App Service pull the image with the managed identity instead of registry credentials.
CSet vnetImagePullEnabled to true on the app
Incorrect
Not needed here; the registry isn't network-restricted.
DSet the WEBSITES_PORT app setting to 8000
Correct
App Service assumes a custom container listens on port 80; WEBSITES_PORT tells it which port to send requests to.
ESet WEBSITES_ENABLE_APP_SERVICE_STORAGE to true
Incorrect
This setting changes neither the port App Service sends requests to nor how the image is pulled.
To pull from Azure Container Registry with a managed identity, assign the identity AcrPull and set acrUseManagedIdentityCreds (plus acrUserManagedIdentityID for a user-assigned identity). A container that doesn't listen on port 80 also needs WEBSITES_PORT, because App Service exposes only one HTTP port to the container.
A registry is set to RBAC Registry + ABAC Repository Permissions. A build pipeline signs in with its own Microsoft Entra workload identity and must push and tag images only in repositories whose names start with team-a/, without being able to touch any other repository. Which role assignment do you create?
AAcrPush, scoped to the registry
BContainer Registry Repository Writer with an ABAC condition on team-a/ repositories
CContributor, scoped to the registry
DA non-Microsoft Entra token whose scope map grants content/write on the team-a/ repositories
Show the answer and why
AAcrPush, scoped to the registry
Incorrect
AcrPull, AcrPush and AcrDelete aren't honored in ABAC-enabled registries, and AcrPush couldn't be limited to some repositories.
BContainer Registry Repository Writer with an ABAC condition on team-a/ repositories
Correct
In ABAC-enabled registries this role grants push, pull and tag management, and the condition scopes it to matching repositories.
CContributor, scoped to the registry
Incorrect
In an ABAC-enabled registry, Contributor grants only control plane rights over the registry resource, not data plane push rights.
DA non-Microsoft Entra token whose scope map grants content/write on the team-a/ repositories
Incorrect
Tokens and scope maps are a separate credential that isn't integrated with Microsoft Entra ID or role assignments, so the pipeline's workload identity wouldn't be used.
ABAC-enabled mode uses a new set of roles: Container Registry Repository Reader, Writer and Contributor. Each can be assigned registry-wide or, with an ABAC condition, to specific repositories. Legacy AcrPull and AcrPush aren't honored, and Owner, Contributor and Reader cover only the control plane.
A scheduled ACR task runs acr purge with --filter "dev/api:.*" and --ago 14d to clean up a development repository. A few older tags in that repository are deployed and have been locked with write-enabled set to false. What does the purge do with those locked tags by default?
AIt deletes them, because the task authenticates with the registry's own identity
BIt stops the whole run with an error at the first locked tag
CIt removes their tags but keeps the manifests and layers
DIt keeps them; locked artifacts are deleted only with --include-locked
Show the answer and why
AIt deletes them, because the task authenticates with the registry's own identity
Incorrect
The task does authenticate automatically, but that doesn't override the lock attributes.
BIt stops the whole run with an error at the first locked tag
Incorrect
Locked artifacts are skipped, not treated as an error for the run.
CIt removes their tags but keeps the manifests and layers
Incorrect
That describes what purge does to unlocked matches without --untagged; locked ones are left completely untouched.
DIt keeps them; locked artifacts are deleted only with --include-locked
Correct
By default acr purge skips any tag or manifest whose write-enabled or delete-enabled attribute is false.
acr purge deletes tags that match the filter and are older than the --ago duration, and only tag references unless you also ask for manifests. It respects image locks: artifacts with write-enabled or delete-enabled set to false survive unless --include-locked unlocks and deletes them.
A developer's laptop can't run Docker Engine, but they need to build an image from the Dockerfile in their working folder and push it to the team's Azure container registry. Which command does that?
Adocker build -t <registry>.azurecr.io/api:dev . followed by docker push
A quick task sends the local context to the registry, builds the image in Azure and, by default, pushes it on completion.
Daz acr login --name <registry> --expose-token, then push the folder with the token
Incorrect
--expose-token returns a registry token for tools without the Docker daemon; it doesn't build an image.
Quick tasks are docker build and docker push in the cloud: az acr build takes a build context (a local folder, a Git repository or a tarball), runs the build on ACR Tasks compute and pushes the result.
The pipeline re-pushes the tag release-candidate several times a day, but a cleanup script must never be able to delete it. Which repository attribute change meets both needs?
read-enabled false blocks pulls of the image; it doesn't stop deletion.
DA CanNotDelete resource lock on the registry in Azure Resource Manager
Incorrect
Locking the registry resource affects management operations only, not creating or deleting data in repositories.
Repository and image attributes control what can happen to content: write-enabled false locks an image completely, delete-enabled false prevents deletion but allows updates, and read-enabled false prevents pulls.
Container Apps deployments occasionally fail because Docker Hub rate limits pulls of a public base image. You want pulls to go through your Azure container registry without writing a pipeline that copies images. What do you set up, and what should you expect after creating it?
AAn artifact cache rule with Docker Hub credentials; images cache on their first pull
BAn artifact cache rule without credentials; the registry copies every tag in the repository when the rule is saved
CA geo-replica in the deployment region so that pulls skip Docker Hub
DAn ACR task with a timer trigger that runs docker pull against Docker Hub every hour
Show the answer and why
AAn artifact cache rule with Docker Hub credentials; images cache on their first pull
Correct
Cache rules pull from the upstream on first use and serve later pulls from ACR; Docker Hub supports authenticated pulls only.
BAn artifact cache rule without credentials; the registry copies every tag in the repository when the rule is saved
Incorrect
Docker Hub cache rules need credentials, and the cache doesn't prefetch tags; each image is cached when it's first pulled.
CA geo-replica in the deployment region so that pulls skip Docker Hub
Incorrect
Geo-replication replicates content already in your registry; it doesn't fetch images from Docker Hub.
DAn ACR task with a timer trigger that runs docker pull against Docker Hub every hour
Incorrect
Pulling in a task doesn't store the image in your registry and still counts against the upstream limit.
Artifact cache lets a registry act as a pull-through cache for public or private upstreams. Credentials for authenticated upstreams such as Docker Hub live in Key Vault, and new tags aren't pulled automatically: each image is cached on its first pull.
A Python app in an App Service Linux custom container reads its settings with os.environ. You add QUEUE_NAME as an app setting. The registry credentials App Service uses are stored in DOCKER_REGISTRY_SERVER_PASSWORD. Which statement is true at run time?
ABoth values are available, because every app setting becomes an environment variable
BQUEUE_NAME is set in the environment; the registry password isn't exposed
CNeither value is available until the image's Dockerfile declares them with ENV
DQUEUE_NAME can be read only on the Kudu /Env page, not from inside the app process
Show the answer and why
ABoth values are available, because every app setting becomes an environment variable
Incorrect
The DOCKER_REGISTRY_SERVER_* variables are reserved and, for security, aren't exposed to the application.
BQUEUE_NAME is set in the environment; the registry password isn't exposed
Correct
App settings are injected into the process as environment variables, but the reserved registry credential names are hidden.
CNeither value is available until the image's Dockerfile declares them with ENV
Incorrect
App Service injects app settings at run time; they don't have to be declared in the image.
DQUEUE_NAME can be read only on the Kudu /Env page, not from inside the app process
Incorrect
The /Env page is a way to verify the variables; the settings themselves are injected into the app's process.
When the app runs, App Service injects app settings into the process as environment variables (visible at the Kudu /Env page). Registry credentials stored in DOCKER_REGISTRY_SERVER_URL, _USERNAME and _PASSWORD aren't exposed to the application.