This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
   --> Implement container application hosting
      --> Build and Run Images by Using Azure Container Registry Tasks

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure Container Registry Tasks (ACR Tasks) provides cloud-based capabilities for building, testing, and managing container images in Azure Container Registry (ACR).

ACR Tasks is particularly useful when developers want to move container image builds into the cloud rather than relying on a locally installed Docker engine. It can support simple on-demand builds, automated builds triggered by source-code or base-image changes, and more sophisticated multi-step workflows involving multiple containers.

For the AI-200: Developing AI Cloud Solutions on Azure exam, you should understand not only how to execute an ACR Task, but also when to use each type of task, how build contexts work, how images are tagged, how multi-step tasks are defined, how tasks are triggered, and how tasks can securely access other resources.

Microsoft’s AI-200 training specifically identifies building and managing container images in the cloud with ACR Tasks and using the Azure CLI to run ACR quick tasks as learning objectives.

1. What Are Azure Container Registry Tasks?

ACR Tasks is a collection of capabilities within Azure Container Registry that allows you to perform container image operations in Azure.

At a high level:

Source Code / Dockerfile
          |
          v
     ACR Task
          |
    +-----+-----+
    |           |
    v           v
   Build       Test
    |           |
    +-----+-----+
          |
          v
    Container Image
          |
          v
          ACR

ACR Tasks can:

• Build container images in Azure
• Push images to ACR
• Run containers as part of a task
• Test container images
• Build multiple images
• Execute steps sequentially or in parallel
• Automatically trigger builds from source-code changes
• Automatically rebuild images when base images change
• Run tasks on a schedule
• Integrate into CI/CD workflows

ACR Tasks supports Linux, Windows, and ARM image platforms, depending on the configuration and supported scenarios.

2. Why Use ACR Tasks?

A traditional container development workflow might look like this:

Developer Computer
       |
       +-- Docker build
       |
       +-- Docker test
       |
       +-- Docker push
       |
       v
Azure Container Registry

This requires the developer’s machine to have the appropriate container tooling.

With an ACR Task:

Developer
    |
    | Azure CLI
    v
Azure Container Registry
    |
    +-- Build
    +-- Test
    +-- Push

The build is performed in Azure.

This has several advantages:

• No local Docker Engine is required for an ACR quick task.
• Builds can be standardized.
• Builds can be automated.
• Container images can be built close to the registry.
• Build workflows can be triggered by source-code changes.
• Base-image updates can automatically initiate rebuilds.
• More complex build/test workflows can be defined using YAML.

Microsoft describes quick tasks as an integrated development experience that offloads container image builds to Azure and can perform the equivalent of docker build and docker push in the cloud.

3. Three Important ACR Task Scenarios

For AI-200, understand these three categories:

These aren’t mutually exclusive concepts.

For example, a multi-step task can also be automatically triggered by a Git commit.

4. Quick Tasks

A quick task is an on-demand container image build performed in Azure.

It is particularly useful during development.

The Azure CLI command is:

az acr build

For example:

az acr build \
    --registry myregistry \
    --image orders-api:v1 \
    .

The final . represents the build context.

Conceptually, this performs:

Dockerfile + build context
          |
          v
      ACR Task
          |
          v
     Build image
          |
          v
      Push image
          |
          v
          ACR

The important point is that the build takes place in Azure rather than requiring a local Docker engine.

ACR Tasks’ quick-build capability is essentially a cloud-based equivalent of performing a Docker build and push operation.

5. Understanding the Build Context

One of the most important concepts when using az acr build is the build context.

Consider:

az acr build \
    --registry myregistry \
    --image orders-api:v1 \
    .

The . specifies the current directory as the build context.

The build context contains files that are available to the Docker build process.

For example:

orders-api/
│
├── Dockerfile
├── requirements.txt
├── app.py
└── src/

Running:

az acr build ... .

makes that directory the build context.

The context can also come from other supported locations, including source repositories.

6. Dockerfile and ACR Tasks

ACR Tasks uses familiar Docker build syntax.

For example:

FROM python:3.12
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

You can then build the image with:

az acr build \
    --registry myregistry \
    --image orders-api:v1 \
    .

The Dockerfile defines how the container image is constructed.

ACR Tasks handles the build environment and performs the build in Azure.

7. Specifying a Dockerfile

If the Dockerfile has a different name or location, specify it using --file.

For example:

az acr build \
    --registry myregistry \
    --image orders-api:v1 \
    --file Dockerfile.production \
    .

You can also specify a Dockerfile located elsewhere relative to the build context.

The important exam concept is:

The build context and Dockerfile are related but are not necessarily the same thing.

The Dockerfile describes the build instructions.

The build context identifies the files available to the build.

8. ACR Tasks Versus Local Docker Builds

Consider this traditional command:

docker build -t orders-api:v1 .

With ACR Tasks, you can use:

az acr build \
    --registry myregistry \
    --image orders-api:v1 \
    .

The conceptual difference is:

This distinction is a likely source of scenario-based exam questions.

9. Building Without a Local Docker Engine

Suppose a developer has:

• Azure CLI
• Access to an Azure Container Registry
• A Dockerfile
• Application source code

but doesn’t have Docker installed.

The developer can still build the image using:

az acr build \
    --registry myregistry \
    --image orders-api:v1 \
    .

This is one of the strongest scenarios for recognizing ACR Tasks on the exam.

10. Running an Image with ACR Tasks

ACR Tasks can also run containers as part of a task.

The cmd step is used for this purpose in multi-step tasks.

For example:

version: v1.1.0
steps:
  - build: -t $Registry/orders-api:$ID .
  - cmd: $Registry/orders-api:$ID

The cmd step runs a container using the specified image.

This makes it possible to use ACR Tasks for testing.

For example:

Build image
    |
    v
Run image
    |
    v
Execute tests
    |
    v
Push image

The cmd step supports parameters similar to familiar container-run operations, including environment variables and detached execution.

11. Multi-Step Tasks

A multi-step task allows you to create a more sophisticated container workflow.

Instead of simply:

Build → Push

you can implement:

Build
  |
  v
Run
  |
  v
Test
  |
  v
Push

You can also build multiple images:

             +--> Build API ----+
             |                  |
Source ------+                  +--> Test --> Push
             |                  |
             +--> Build Worker -+

Multi-step tasks are defined in a YAML file.

Microsoft identifies three primary ACR Tasks step types:

• build
• push
• cmd

12. The build Step

The build step builds a container image.

Example:

version: v1.1.0
steps:
  - build: -t $Registry/orders-api:$ID .

Conceptually, this is similar to:

docker build

but the build is performed within the ACR Tasks environment.

The image name should identify the image that the task builds.

13. The push Step

The push step pushes an image to a container registry.

Example:

version: v1.1.0
steps:
  - build: -t $Registry/orders-api:$ID .
  - push:
      - $Registry/orders-api:$ID

The build step creates the image.

The push step publishes it to the registry.

An important exam distinction is that in a multi-step az acr run task, you should not assume that a built image is automatically pushed simply because it was built. The task definition can explicitly use a push step to publish it.

14. The cmd Step

The cmd step executes a container.

For example:

version: v1.1.0
steps:
  - cmd: bash:3.0 echo "Hello from ACR Tasks"

It can also execute an image produced by an earlier build:

version: v1.1.0
steps:
  - build: -t $Registry/orders-api:$ID .
  - cmd: $Registry/orders-api:$ID

This is especially useful for testing.

The cmd step can use environment variables and other execution options.

15. Build, Test, and Push

A common ACR Tasks pattern is:

version: v1.1.0
steps:
  - build: -t $Registry/orders-api:$ID .
  - cmd: $Registry/orders-api:$ID
  - push:
      - $Registry/orders-api:$ID

Conceptually:

             BUILD
               |
               v
          Container Image
               |
               v
              TEST
               |
         Tests successful
               |
               v
              PUSH
               |
               v
              ACR

This pattern can prevent an image from being pushed until validation has occurred.

16. Step Dependencies

ACR Tasks allows steps to have dependencies.

The when property can specify which previous steps must complete before a step executes.

For example:

version: v1.1.0
steps:
  - id: build
    build: -t $Registry/orders-api:$ID .
  - id: test
    cmd: $Registry/orders-api:$ID
    when: ["build"]
  - id: push
    push:
      - $Registry/orders-api:$ID
    when: ["test"]

The sequence is:

build
  |
  v
test
  |
  v
push

This allows the task to express workflow dependencies explicitly.

17. Parallel Execution

ACR Tasks can also execute independent steps concurrently.

For example:

version: v1.1.0
steps:
  - id: build-api
    build: -t $Registry/api:$ID .
    when: ["-"]
  - id: build-worker
    build: -t $Registry/worker:$ID ./worker
    when: ["-"]

The special:

when: ["-"]

indicates that the step has no dependency on another step and can begin immediately.

Therefore:

        +--> Build API ---+
        |                 |
START --+                 +--> Continue
        |                 |
        +--> Build Worker-+

This can reduce total task execution time when operations are independent.

Microsoft’s ACR Tasks YAML reference specifically documents when: ["-"] for steps that have no dependency and can execute concurrently.

18. Build Dependencies Versus Sequential Steps

If when isn’t specified, a step is dependent on the previous step in the task definition.

For example:

steps:
  - id: build
    build: -t $Registry/api:$ID .
  - id: test
    cmd: $Registry/api:$ID
  - id: push
    push:
      - $Registry/api:$ID

This naturally produces:

build → test → push

If explicit dependencies are needed, use when.

19. Running an ACR Task

The Azure CLI command commonly used to execute a task definition is:

az acr run

For example:

az acr run \
    --registry myregistry \
    --file acr-task.yaml \
    .

You can also use a Git repository as the context.

For example:

az acr run \
    --registry myregistry \
    --file acr-task.yaml \
    https://github.com/example/project.git

The task receives the specified source context and executes the defined workflow.

20. az acr build Versus az acr run

This is an important distinction for AI-200.

az acr build

Designed primarily for a quick cloud-based image build.

Example:

az acr build \
    --registry myregistry \
    --image orders-api:v1 \
    .

Think:

Build an image quickly in Azure.

az acr run

Executes an ACR Tasks workflow.

Example:

az acr run \
    --registry myregistry \
    --file acr-task.yaml \
    .

Think:

Run a defined task workflow.

A multi-step task uses az acr run.

21. ACR Tasks Run Variables

ACR Tasks provides built-in run variables.

These variables can be used to create standardized image names and tags.

One particularly useful variable is:

Run.ID

which can be represented in task YAML using the $ID alias.

For example:

steps:
  - build: -t $Registry/orders-api:$ID .

This gives each task run a unique identifier that can be incorporated into the image tag.

ACR Tasks also provides variables associated with:

• Registry
• Registry name
• Run ID
• Date
• Operating system
• Architecture
• Git commit
• Git branch
• Task name

22. Why Use Unique Build Tags?

Suppose every build uses:

orders-api:latest

You lose an easy way to distinguish individual builds.

Instead, you could use:

orders-api:build-123
orders-api:build-124
orders-api:build-125

ACR Tasks’ run ID can help automate this.

For example:

steps:
  - build: -t $Registry/orders-api:$ID .
  - push:
      - $Registry/orders-api:$ID

This produces unique image references for individual runs.

This is especially useful for CI/CD scenarios.

23. Automatically Triggered Tasks

ACR Tasks can automatically execute based on events.

Important trigger scenarios include:

Source-code updates

A task can run when code is committed to a supported Git repository.

For example:

Developer commits code
        |
        v
Git repository
        |
        v
ACR Task trigger
        |
        v
Build image
        |
        v
Push image

Base-image updates

A task can be triggered when a base image changes.

For example:

FROM python:3.12

If the base image is updated, an ACR Task can rebuild the application image.

This is useful for automatically incorporating updated OS or framework components.

Scheduled execution

ACR Tasks can also support scheduled execution.

For example:

Every night
     |
     v
ACR Task
     |
     v
Build/test image

Microsoft documents source-code, base-image, and timer-based triggers as ACR Tasks automation scenarios.

24. Base Image Update Triggers

Base image triggers are especially relevant to security and maintenance.

Suppose:

FROM ubuntu:24.04

A security update causes a newer version of the base image to become available.

Without automation:

Base image updated
       |
       X
Application image remains unchanged

With an ACR Task:

Base image updated
       |
       v
ACR Task trigger
       |
       v
Rebuild application image
       |
       v
Push updated image

This allows organizations to automatically rebuild images when their dependencies change.

Microsoft describes this scenario as a way to automate OS and framework patching for container images.

25. Source-Code Triggers

ACR Tasks can integrate with source repositories.

For example:

Git commit
    |
    v
ACR Task
    |
    +-- Build
    +-- Test
    +-- Push

This provides a simple cloud-based container CI workflow.

A task can be configured to respond to commits and, depending on the configuration, pull-request activity in supported Git repositories.

26. Multi-Container Workflows

ACR Tasks becomes particularly valuable when an application contains multiple containers.

Suppose you have:

Web API
Worker
Test suite

You could define:

Build API
    |
Build Worker
    |
Run tests
    |
Push API
    |
Push Worker

Or independent builds could execute concurrently:

            +--> Build API -----+
            |                   |
START ------+                   +--> Test --> Push
            |                   |
            +--> Build Worker --+

Multi-step tasks are designed specifically for these types of workflows.

27. ACR Tasks and CI/CD

ACR Tasks can be incorporated into a broader CI/CD architecture.

For example:

Developer
    |
    v
Git Repository
    |
    v
ACR Task
    |
    +--> Build
    |
    +--> Test
    |
    +--> Push
    |
    v
Azure Container Registry
    |
    v
Container Apps / AKS / App Service

ACR Tasks is therefore not merely a command for building images. It can serve as a container lifecycle building block within an automated development process.

28. Accessing Other Registries

An ACR Task may need to access images or artifacts outside the registry where the task runs.

For example:

ACR Task
   |
   | Pull base image
   v
External Registry

or:

ACR Task
   |
   | Push image
   v
Another Registry

ACR Tasks supports authentication mechanisms for accessing protected resources.

Managed identities are particularly useful when an ACR Task needs to access other Azure resources without embedding credentials in the task definition.

Microsoft documents both system-assigned and user-assigned managed identities for ACR Tasks.

29. Managed Identities for ACR Tasks

An ACR Task can have a managed identity.

Two types are available:

System-assigned managed identity

The identity is associated with the specific ACR Task resource.

Its lifecycle is tied to that resource.

User-assigned managed identity

The identity is an independent Azure resource that can be assigned to multiple resources.

This can be useful when the same identity needs to be reused.

The key exam concept is:

Managed identities allow ACR Tasks to access protected Azure resources without embedding credentials in the task definition.

30. ACR Tasks and Azure Key Vault

ACR Tasks can also integrate with Azure Key Vault for scenarios where a task needs access to secrets.

A secure architecture might look like:

                 Azure Key Vault
                       |
                       | Secret
                       v
ACR Task ------ Managed Identity
                       |
                       v
                  Build/Test

This is preferable to hard-coding credentials into Dockerfiles, scripts, or task definitions.

31. Security Considerations

When designing ACR Task workflows:

Avoid putting secrets directly on command lines

Command-line arguments can potentially be captured by diagnostic or logging systems.

Avoid embedding credentials in Dockerfiles

A Dockerfile should not contain permanent passwords, tokens, or keys.

Prefer managed identities

When the target resource supports identity-based authentication, managed identities reduce credential-management overhead.

Use least privilege

Give the task only the permissions it needs.

Be careful with external registry credentials

If a task must access another private registry, configure authentication appropriately rather than placing credentials in source code.

Microsoft specifically warns that information supplied through command lines or URIs can appear in ACR diagnostic tracing, including sensitive values.

32. Task YAML Structure

A basic multi-step task looks like:

version: v1.1.0
steps:
  - build: -t $Registry/orders-api:$ID .
  - push:
      - $Registry/orders-api:$ID

A more sophisticated task could look like:

version: v1.1.0
steps:
  - id: build-api
    build: -t $Registry/orders-api:$ID .
  - id: test-api
    cmd: $Registry/orders-api:$ID
    when: ["build-api"]
  - id: push-api
    push:
      - $Registry/orders-api:$ID
    when: ["test-api"]

The key elements are:

ACR Tasks currently supports YAML as the task-definition format.

33. A Complete Build-Test-Push Example

Consider an API application with:

Dockerfile
src/
tests/

A multi-step task could conceptually perform:

version: v1.1.0
steps:
  - id: build
    build: -t $Registry/orders-api:$ID .
  - id: test
    cmd: $Registry/orders-api:$ID
    when: ["build"]
  - id: push
    push:
      - $Registry/orders-api:$ID
    when: ["test"]

The workflow becomes:

                  +----------------+
                  |     Source     |
                  +-------+--------+
                          |
                          v
                       BUILD
                          |
                          v
                    Container Image
                          |
                          v
                        TEST
                          |
                    Tests pass
                          |
                          v
                        PUSH
                          |
                          v
                         ACR

This is an excellent pattern to recognize in scenario-based questions.

34. az acr build Versus Multi-Step Tasks

A useful exam comparison is:

35. Common Exam Traps

Trap 1: Choosing Azure Container Instances

ACR Tasks is about building and managing container image workflows.

Azure Container Instances is primarily about running containers.

If the question says:

“Build a container image in Azure without installing Docker locally.”

Think:

ACR Tasks

not Azure Container Instances.

Trap 2: Confusing ACR with ACR Tasks

ACR is the registry.

ACR Tasks provides cloud-based build and automation capabilities.

Think:

ACR
 ↓
Store images
ACR Tasks
 ↓
Build/test/automate images

Trap 3: Assuming az acr run and az acr build are identical

They are not.

az acr build is designed for the quick cloud build scenario.

az acr run executes a task definition or command in the ACR Tasks environment.

Trap 4: Assuming every build automatically pushes an image

For a quick az acr build, the resulting image is pushed to the registry by default.

For an az acr run multi-step task, you should explicitly define a push step when you want to push the built image.

This distinction is explicitly documented in the ACR Tasks YAML reference.

Trap 5: Using cmd when you need to build an image

cmd runs a container.

build builds a container image.

Remember:

build → create image
cmd   → run container
push  → publish image

Trap 6: Ignoring the build context

The build context determines what files are available to the Docker build.

A Dockerfile alone isn’t necessarily sufficient if it references files from the context.

Trap 7: Putting secrets in the Dockerfile

Never assume that a secret belongs in:

ENV PASSWORD=...

or:

RUN some-command --password ...

Use appropriate Azure identity and secret-management mechanisms instead.

36. AI-200 Exam-Focused Review

Make sure you understand the following:

ACR Tasks

Cloud-based container build and automation capabilities.

Quick task

On-demand image build, commonly using:

az acr build

az acr run

Executes an ACR task workflow or command.

Build context

The files supplied to the container build.

build

Builds a container image.

push

Pushes an image to a registry.

cmd

Runs a container as part of a task.

when

Defines dependencies between task steps.

$Registry

Identifies the registry associated with the task run.

$ID

Identifies the current task run and can be used to generate unique tags.

Multi-step task

Supports complex workflows involving building, testing, running, and pushing containers.

Source trigger

Automatically runs a task when supported source-code changes occur.

Base-image trigger

Automatically rebuilds images when a base image changes.

Scheduled trigger

Runs tasks according to a schedule.

Managed identity

Allows a task to access protected Azure resources without embedding credentials.

37. The Mental Model to Remember

For AI-200, think of ACR Tasks as a cloud-based container build and automation engine attached to Azure Container Registry.

                    SOURCE
                       |
             +---------+---------+
             |                   |
          Dockerfile          Git Repo
             |                   |
             +---------+---------+
                       |
                       v
                  ACR TASK
                       |
          +------------+------------+
          |            |            |
        BUILD         CMD         PUSH
          |            |            |
          |          TEST           |
          |            |            |
          +------------+------------+
                       |
                       v
                  ACR IMAGE
                       |
                       v
             Container Service
        +----------+----------+
        |          |          |
       AKS    Container Apps  App Service

The most important distinction is:

ACR stores the image; ACR Tasks builds, tests, and automates the image lifecycle.

Practice Exam Questions

Question 1

A developer has a Dockerfile and application source code but does not have Docker installed locally. The developer needs to build the image in Azure and store it in an Azure Container Registry.

Which command should the developer use?

A. az container create

B. az acr repository create

C. az acr build

D. az aks create

Answer: C

Explanation: az acr build performs a cloud-based container image build using Azure Container Registry Tasks. The build occurs in Azure, so a local Docker Engine isn’t required for this scenario. The command can build and push the resulting image to ACR.

Question 2

A development team wants to create an automated workflow with the following steps:

1. Build an API container image.
2. Run the image.
3. Execute functional tests.
4. Push the image only if the tests succeed.

Which ACR Tasks capability should be used?

A. A multi-step task

B. ACR geo-replication

C. An ACR repository

D. An Azure Container Apps revision

Answer: A

Explanation: Multi-step ACR Tasks are designed for workflows that combine multiple container operations. The build, cmd, and push step types can be combined, and dependencies can be defined using the when property. This allows testing to occur before the image is pushed.

Question 3

An ACR Task contains the following YAML:

steps:
  - id: build
    build: -t $Registry/api:$ID .
  - id: test
    cmd: $Registry/api:$ID
    when: ["build"]
  - id: push
    push:
      - $Registry/api:$ID
    when: ["test"]

What is the purpose of when: ["test"] on the final step?

A. It causes the push to run before testing

B. It causes the push to run concurrently with testing

C. It causes the push step to be skipped

D. It makes the push step dependent on successful completion of the test step

Answer: D

Explanation: The when property establishes dependencies between task steps. Here, the push step depends on the step identified as test, so it won’t execute until the test step completes successfully.

Question 4

An organization wants an ACR Task to automatically rebuild application images whenever a new version of a base image becomes available.

Which trigger should be configured?

A. A repository namespace trigger

B. A base-image update trigger

C. A container restart trigger

D. An Azure Monitor alert trigger

Answer: B

Explanation: ACR Tasks supports base-image update triggers. When the configured base image changes, the task can automatically rebuild the application image. This is particularly useful for incorporating updated operating-system and framework components.

Question 5

An ACR Task needs to execute two independent image builds at the same time. Which YAML configuration allows the steps to start without depending on another task step?

A. when: ["-"]

B. when: ["parallel"]

C. when: ["async"]

D. when: ["none"]

Answer: A

Explanation: In ACR Tasks, when: ["-"] indicates that the step has no dependency on another step and can begin immediately. This can allow independent steps to execute concurrently.

Question 6

A developer wants to create a unique container image tag for every ACR Task execution. Which ACR Tasks variable is specifically designed to identify the current task run?

A. $Branch

B. $Registry

C. $ID

D. $Architecture

Answer: C

Explanation: $ID is an ACR Tasks alias for the current run ID. It can be used to create unique image tags, such as:

-t $Registry/api:$ID

This is useful for distinguishing images produced by different task executions.

Question 7

A multi-step ACR Task has the following steps:

steps:
  - build: -t $Registry/api:$ID .
  - push:
      - $Registry/api:$ID

What is the primary purpose of the push step?

A. Run the container

B. Upload the built image to a container registry

C. Compile the Dockerfile

D. Create an Azure Container Apps revision

Answer: B

Explanation: The push step publishes a built or retagged container image to a container registry. The build step creates the image; push publishes it.

Question 8

An organization wants an ACR Task to execute whenever developers commit code to a supported Git repository. Which capability should be configured?

A. A source-code trigger

B. An ACR retention policy

C. An ACR private endpoint

D. A container health probe

Answer: A

Explanation: ACR Tasks supports source-code triggers that can automatically execute builds or multi-step tasks when changes occur in supported Git repositories. This provides a simple mechanism for integrating container builds into a CI workflow.

Question 9

An ACR Task must access a protected Azure resource. The organization doesn’t want credentials embedded in the task definition.

Which approach provides the most appropriate Azure-native solution?

A. Store the credential in the Dockerfile

B. Put the password in the task’s command line

C. Use a managed identity for the ACR Task

D. Make the Azure resource publicly accessible

Answer: C

Explanation: ACR Tasks can use system-assigned or user-assigned managed identities to access protected resources without embedding credentials in task definitions. The identity must be granted the required permissions on the target resource.

Question 10

A developer executes:

az acr build \
    --registry myregistry \
    --image orders-api:v2 \
    .

What does the final . represent?

A. The ACR registry name

B. The image tag

C. The Docker image digest

D. The build context

Answer: D

Explanation: The final . specifies the current directory as the build context. Files in the build context are made available to the Docker build process. The Dockerfile and files referenced during the build generally need to be available through the selected context.

Key Takeaways

For the AI-200 exam, remember these relationships:

The single most useful mental model for this objective is:

                  ACR TASKS
                      |
       +--------------+--------------+
       |              |              |
     BUILD           CMD            PUSH
       |              |              |
   Create image    Run/test       Publish image
       |              |              |
       +--------------+--------------+
                      |
                      v
                     ACR

And when the exam gives you a scenario, ask:

1. Do I need to build an image in Azure? → az acr build / ACR Tasks
2. Do I need multiple build/test/run operations? → Multi-step ACR Task
3. Do I need to execute a container? → cmd
4. Do I need to publish an image? → push
5. Do steps have dependencies? → when
6. Do independent steps need to run concurrently? → when: ["-"]
7. Should builds happen automatically after source changes? → Source trigger
8. Should images rebuild when a base image changes? → Base-image trigger
9. Does the task need secure access to another Azure resource? → Managed identity
10. Do I need unique image versions for task runs? → Use $ID in the image tag

These distinctions are especially important because AI-200 scenario questions are likely to test which ACR Tasks capability best fits a particular development or deployment requirement, rather than simply asking you to recall an individual command.

Go to the AI-200 Exam Prep Hub main page