1.2 ACR Tasks: Build & Run Images

ACR does more than store images. Azure Container Registry Tasks let you build and run images on Azure-managed infrastructure. For AI-200, Tasks are the cloud-native way to produce images for App Service and other hosts without maintaining your own Docker build VMs—especially useful when you iterate on API containers, scoring sidecars, or GPU-prep images that must land in a private registry quickly.

What ACR Tasks Solve

Traditional pipelines often look like: agent installs Docker → docker build → docker push. That works, but agents need Docker privileges, disk for layers, and ongoing patching. ACR Tasks shift the build into Azure:

• You supply a Dockerfile and build context (or a Git repository).
• ACR builds the image near the registry.
• The resulting image is stored in the same registry (or another you specify).
• Optional steps can run a container for tests or utility commands.

This keeps credentials and artifacts inside Azure and aligns with private-registry workflows.

Quick Tasks Versus Automatic Tasks

Quick builds with az acr build

az acr build packages your local context (or uses remote context), uploads it, builds with the specified Dockerfile, and pushes tags you request. Example conceptual flow:

1. Developer finishes a FastAPI scoring service Dockerfile.
2. Runs az acr build --registry contoso --image scoring:1.3 .
3. ACR builds remotely; contoso.azurecr.io/scoring:1.3 appears without a local Docker daemon push chain.

This is ideal when corporate laptops block Docker Desktop, or when you want consistent Linux amd64 builds from any client.

Running with az acr run

az acr run executes a command or multi-step file in an environment that can authenticate to your registry. Use it to:

• Run a one-off container for smoke tests
• Execute maintenance scripts that need registry access
• Validate that a newly built image starts and responds on a health endpoint before App Service CD promotes it

Building and running are related but distinct exam ideas: build produces an image; run exercises an image or shell steps in ACR’s task agent.

Trigger Types for Automatic Tasks

Automatic Tasks watch for events and rebuild without a person running CLI each time.

1. Source code triggers

Connect ACR Tasks to GitHub or Azure Repos. On commit or pull request to a watched branch, ACR clones the repo and builds. Map branches to tags (main → prod, develop → dev) so App Service slots can track the right channel.

2. Schedule triggers

Cron-like schedules rebuild images on a cadence—useful for:

• Refreshing images that bake weekly dependency updates
• Nightly builds of training-support tooling containers
• Rebuilding documentation or batch-job images that change infrequently but must stay current with base patches

3. Base image update triggers

This is a high-value ACR feature. If your application Dockerfile starts FROM contoso.azurecr.io/dotnet/aspnet:8.0 (or a tracked public base), and that base image receives a new version, ACR can automatically rebuild dependent application images. That shortens the window where production apps run on bases with known CVEs.

Exam cue: when the scenario emphasizes patching OS/runtime bases across many app images without rewriting pipelines, think base image update trigger, not only a git webhook.

Multi-Step Tasks (YAML)

Simple builds use a Dockerfile alone. Multi-step Tasks describe a sequence in YAML, for example:

1. Build the application image
2. Run unit/integration tests in a container
3. Push only if tests succeed
4. Optionally purge old tags or notify a webhook

Multi-step definitions turn ACR into a lightweight cloud build orchestrator. You still may use Azure DevOps or GitHub Actions for broader CI; ACR Tasks shine when the artifact goal is “image in this registry” with registry-native triggers.

Platform Agents and Architecture

ACR Tasks run on Microsoft-managed agents. Specify platform OS/architecture when you need arm64 versus amd64 images for App Service or Container Apps. Mismatched architecture is a common deploy failure: the image builds as arm64 on a developer Mac flow, but App Service Linux expects linux/amd64 unless you configured otherwise. Explicit --platform (or equivalent task property) keeps AI service containers portable.

Authentication and Identity for Tasks

Tasks need permission to push to the registry and, for source triggers, to clone repositories.

• Registry push uses the task’s identity tied to the ACR resource.
• Source control uses a service connection / credentials you configure when creating the task.
• Prefer least privilege: Tasks that only build a subset of repositories should not use broad Owner rights.

When App Service later pulls the image, that is a separate identity (app managed identity + AcrPull). Do not confuse build-time push rights with runtime pull rights.

Designing a Practical Build Flow for AI Workloads

A representative AI-200-style pipeline:

1. Source trigger on main builds inference-api:{{.Run.ID}} and also tags inference-api:prod-candidate.
2. Multi-step task runs a containerized smoke test against the candidate tag.
3. On success, a release process (or second task) retags/digest-pins for App Service continuous deployment.
4. Base image triggers rebuild when the team’s approved aspnet or python base updates in ACR.
5. Schedule weekly rebuilds catch dependency drift even without base events.

Failure modes to remember

• Build context too large → slow uploads; use .dockerignore.
• Task lacks push permission → build succeeds locally in agent but cannot store the image.
• Trigger fires on every commit to a noisy branch → cost and tag churn; narrow branch filters.
• Base image trigger disabled → security patches stall until someone rebuilds manually.

How Tasks Fit the Broader Domain

ACR Tasks sit between “I have a Dockerfile” and “App Service hosts my container.” They do not replace App Service configuration (WEBSITES_PORT, app settings); they produce the image those hosts consume. On the exam, if the question is about building in Azure or rebuilding when bases change, answer with ACR Tasks. If the question is about serving HTTP traffic from a container, move to App Service (next section) or Container Apps/AKS in later chapters.

Used well, ACR Tasks give you cloud builds, event-driven rebuilds, and optional run steps—without turning every developer laptop into a privileged Docker host.