3.1.2. ACR Tasks
💡 First Principle: Images decay even when your code doesn't — the base image beneath you accumulates CVEs. So building must be reactive, not just on-demand: rebuild when code changes, and crucially, rebuild when the foundation changes. ACR Tasks moves the build into the registry itself, where both signals are visible.
The simplest mode is the quick task: az acr build --registry myreg --image rag-api:{{.Run.ID}} . uploads your build context and builds in Azure — no local Docker daemon needed, which is exactly the answer when a scenario says "build from a machine without Docker installed."
The real power is triggered tasks, created with az acr task create:
The base image update trigger is the exam's favorite because it's the capability people don't know exists: ACR tracks the FROM line of your Dockerfile, and when python:3.12-slim gets a security patch upstream, your dependent images rebuild automatically. "Ensure images are rebuilt when the base OS image is patched" has exactly one right answer, and this is it.
For pipelines beyond a single build, multi-step tasks defined in YAML run sequences — build, then test, then push conditionally — turning ACR into a lightweight container CI system:
version: v1.1.0
steps:
- build: -t $Registry/rag-api:$ID .
- cmd: $Registry/rag-api:$ID pytest /app/tests
- push: ["$Registry/rag-api:$ID"]
Connecting back to 3.1.1's warehouse model: quick tasks stock a shelf once; triggered tasks are the standing restock orders that keep the warehouse current without a human in the loop.
⚠️ Exam Trap: ACR Tasks are not only on-demand builds — commit triggers, base image update triggers, and schedules are core capabilities. When a scenario asks for automatic rebuilds on upstream patches without adding a CI system, the answer is an ACR Task with a base image trigger, not GitHub Actions.
Reflection Question: Your Dockerfile starts FROM python:3.12-slim. Upstream patches a critical CVE in that image. With only commit triggers configured, what happens — and what should?
