ACR Tasks: Automated Image Builds

What ACR Tasks is

The three flavours

ACR Tasks comes in three flavours. Use the simplest one that fits.

Feature	Quick task	Triggered task	Multi-step task
Command	`az acr build`	`az acr task create` + `az acr task run`	`az acr task create -f acr-task.yaml`
Triggered by	Manually, from CLI	git push, base-image update, schedule, manual run	Same as triggered task; runs the YAML
What it does	Builds + pushes one image	Builds + pushes one image, repeatedly	Build, test, scan, push, run external commands — multiple steps
When to use	Replace local `docker build` for slow laptops or CI	Auto-rebuild on commits or base-image patches	Full pipeline (build → test → push → deploy webhook)

Quick task — your daily driver

A quick task replaces docker build && docker push on your laptop. The build runs on Azure infrastructure, the result lands in your ACR, and you save the bandwidth of pushing a multi-GB image over your home internet.

# From the directory containing your Dockerfile:
az acr build \
  --registry roo \
  --image roo-vision:v3.4.1 \
  --image roo-vision:latest \
  --file Dockerfile .

The dot at the end is the build context — ACR Tasks zips the directory and uploads it. The build runs in the same region as your registry, so the resulting image push is internal and fast.

ℹ️ Why Mira always uses `az acr build` over `docker build`

Mira’s vision image is 4.2 GB. Building locally:

• Pull the 3.5 GB CUDA base image to her laptop (≈12 minutes on home Wi-Fi)
• Run the build (8 minutes)
• Push 4.2 GB back to ACR (≈18 minutes)

Total: 38 minutes, hammering her connection.

Building with az acr build:

• Upload the build context only — a few KB of Dockerfile + Python source (5 seconds)
• Build runs in the same Azure region as ACR (8 minutes)
• Push is internal Azure traffic (30 seconds)

Total: under 9 minutes, no laptop bandwidth used. ACR Tasks pays for itself the first day.

Triggered tasks — the killer feature for AI

A triggered task is a stored definition that runs whenever something changes. Three trigger types:

Trigger	Fires when	Best for
Source code	Commit lands on a tracked git branch (GitHub, Azure DevOps)	Continuous delivery — every commit produces a fresh image
Base image update	The base image referenced in your FROM line is updated in ACR or Microsoft Container Registry	Auto-patching — Python or Ubuntu CVE → your image rebuilds within minutes
Timer	A cron schedule	Nightly rebuilds, weekly patch refreshes

# Source code trigger — rebuild on every commit to main
az acr task create \
  --name roo-vision-build \
  --registry roo \
  --image roo-vision:{{.Run.ID}} \
  --image roo-vision:latest \
  --context https://github.com/roo-robotics/vision \
  --file Dockerfile \
  --branch main \
  --git-access-token $GITHUB_PAT

Note the {{.Run.ID}} template — every build gets a unique tag, plus the moving :latest.

Base-image update triggers — the security story

This is the feature you’ll see most on the exam. When you reference a base image (FROM python:3.12-slim), ACR Tasks watches the upstream image. The instant a new digest is published, ACR Tasks rebuilds your downstream image and pushes a new tag. You did nothing.

# Dockerfile
FROM mcr.microsoft.com/azure-functions/python:4-python3.12
COPY . /app
RUN pip install -r requirements.txt
CMD ["python", "-m", "function_host"]

The day Microsoft ships a Python 3.12 patch, your image rebuilds automatically — assuming you created the task with --base-image-trigger Runtime (the default) and a tracked tag.

💡 Exam tip: distinguish 'patch the OS' from 'patch the framework'

Base-image update triggers track the direct base image referenced in FROM. They do not chase the OS layer underneath that base image unless that’s the layer you depend on.

Premium tier adds automatic OS / framework patching — ACR can patch the OS layer of an image without rebuilding from source. That’s a Premium-only feature; Basic and Standard cannot.

Multi-step tasks — full pipelines in YAML

When a single build isn’t enough — build, test, scan, push, then notify — multi-step tasks let you express the whole flow in a YAML file.

# acr-task.yaml
version: v1.1.0
steps:
  - id: build
    build: -t {{.Run.Registry}}/roo-vision:{{.Run.ID}} -f Dockerfile .

  - id: test
    cmd: roo/test-runner:latest
    when: ["build"]
    env:
      - IMAGE={{.Run.Registry}}/roo-vision:{{.Run.ID}}

  - id: scan
    cmd: aquasec/trivy image {{.Run.Registry}}/roo-vision:{{.Run.ID}}
    when: ["build"]

  - id: push
    push:
      - {{.Run.Registry}}/roo-vision:{{.Run.ID}}
    when: ["test", "scan"]

when controls dependencies — test and scan both wait on build, then push waits on both. Steps without when run in parallel.

Authentication — managed identity inside the task

ACR Tasks runs with its own identity. Assign that identity roles on whatever Azure resources the task needs:

# Create a task with a system-assigned managed identity
az acr task create \
  --name nightly-build \
  --registry roo \
  --image worker:nightly \
  --context $GIT \
  --schedule "0 2 * * *" \
  --assign-identity [system]

# Grant the identity AcrPush on the registry
az role assignment create \
  --assignee $(az acr task show -n nightly-build -r roo --query identity.principalId -o tsv) \
  --role AcrPush \
  --scope $(az acr show -n roo --query id -o tsv)

The task pushes images to the registry without storing a password.

Key terms

Question

What is an ACR Tasks quick task?

Click or press Enter to reveal answer

Answer

A one-off cloud-side container build invoked with `az acr build`. It zips your local context, uploads it, builds in the same region as the registry, and pushes the result. Replaces `docker build && docker push` with no local CPU or bandwidth use.

Click to flip back

Question

What does a base-image update trigger do in ACR Tasks?

Click or press Enter to reveal answer

Answer

Watches the base image referenced in your Dockerfile's `FROM` line. When a new digest of the base is published, ACR Tasks automatically rebuilds your image and pushes a new tag — a key supply-chain hardening feature for AI workloads with frequent ML/Python CVEs.

Click to flip back

Question

What is a multi-step ACR task?

Click or press Enter to reveal answer

Answer

A task defined in YAML with multiple steps (build, test, scan, push, exec). Steps can run in parallel or with `when:` dependencies. Lets you express a full image pipeline inside ACR without external CI.

Click to flip back

Question

Which ACR feature lets the task push images without a stored password?

Click or press Enter to reveal answer

Answer

Managed identity for the task. Assign a system- or user-assigned identity to the task, grant it AcrPush (or AcrPull) on the relevant registry, and the task authenticates via Microsoft Entra without secrets in the YAML.

Click to flip back

Knowledge check

Knowledge Check

Mira's vision image is built from `FROM python:3.12-slim`. She wants the image to rebuild automatically when a Python 3.12 CVE patch is published, without anyone running a build manually. Which ACR Tasks feature should she configure?

AA timer-based task that rebuilds nightly regardless of changesBA source-code trigger on the application repoCA base-image update trigger so the task fires when the upstream Python image changesDManual `az acr build` after every announcement

Check Answer

Knowledge Check

Lin needs to run a build, run unit tests against the built image, scan it for vulnerabilities, and only push if both test and scan succeed. What's the cleanest fit in ACR Tasks?

ASeveral quick tasks chained with shell scriptsBA multi-step task with `when:` dependencies between build, test, scan, and pushCA timer-triggered task running every five minutesDGitHub Actions calling `az acr build` four separate times

Check Answer

Knowledge Check

An ACR task pushes images to its host registry. What's the recommended way for the task to authenticate to the registry?

AStore an admin password in the task definitionBUse a service principal whose secret is mounted as an environment variableCAssign the task a managed identity and grant it the AcrPush role on the registryDGenerate a SAS token at task-create time

Check Answer