Tag: Cloud Solutions

AI-200, azure, Microsoft Certification

Deploy and manage applications to Azure Kubernetes Service (AKS) by using manifest files (AI-200 Exam Prep)

 
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-orchestrated solutions
      --> Deploy and manage applications to Azure Kubernetes Service (AKS) by using manifest files

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 Kubernetes Service (AKS) provides a managed Kubernetes environment for deploying and operating containerized applications. For AI solutions, AKS can be particularly useful when applications require container orchestration, multiple cooperating services, custom networking, persistent workloads, or more control over Kubernetes configuration.

One of the fundamental skills for working with AKS is the ability to define and deploy applications by using Kubernetes manifest files.

A Kubernetes manifest is a declarative configuration file, commonly written in YAML, that describes the desired state of Kubernetes resources. Rather than manually creating each resource with individual commands, developers can define the application’s resources in one or more manifest files and use kubectl to apply those definitions to an AKS cluster.

The AI-200 exam expects you to understand how these manifests are structured, how they are deployed, how Kubernetes resources work together, and how to manage and troubleshoot the resulting application.

1. Understanding Kubernetes Manifest Files

A Kubernetes manifest describes one or more Kubernetes resources.

A typical manifest specifies information such as:

  • The resource type
  • The resource name
  • The container image
  • The number of replicas
  • Container ports
  • Environment variables
  • Resource requests and limits
  • Configuration references
  • Secrets
  • Health probes
  • Labels and selectors
  • Service configuration
  • Storage requirements

A manifest is declarative.

That distinction is important.

Instead of telling Kubernetes:

Start three containers, then create a network endpoint, then connect the endpoint to those containers.

you describe the desired state:

I want a Deployment with three replicas and a Service that selects those replicas.

Kubernetes controllers continuously work toward making the actual state of the cluster match the desired state defined by the manifests.

2. YAML Manifest Structure

A basic Kubernetes manifest typically contains:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ai-api
  template:
    metadata:
      labels:
        app: ai-api
    spec:
      containers:
        - name: ai-api
          image: myregistry.azurecr.io/ai-api:v1
          ports:
            - containerPort: 8080

The major sections are:

PropertyPurpose
apiVersionSpecifies the Kubernetes API version used by the resource
kindSpecifies the type of Kubernetes resource
metadataProvides identifying information such as name and labels
specDefines the desired configuration of the resource

For the exam, be comfortable recognizing the relationship between these sections.

3. The apiVersion Property

apiVersion identifies the API group and version used to create the resource.

For example:

apiVersion: apps/v1

is commonly used for a Deployment.

A Service generally uses:

apiVersion: v1

The API version matters because Kubernetes resources belong to different API groups and versions.

For example:

apiVersion: apps/v1
kind: Deployment

is different from:

apiVersion: v1
kind: Service

The apiVersion must be appropriate for the resource being defined.

4. The kind Property

The kind property identifies the Kubernetes resource being created.

Common resources include:

  • Deployment
  • Service
  • Pod
  • ConfigMap
  • Secret
  • StatefulSet
  • Job
  • CronJob
  • Ingress
  • HorizontalPodAutoscaler

For AI-200, pay particular attention to Deployment and Service, as these are fundamental to deploying and exposing applications.

5. Kubernetes Deployments

A Deployment manages a set of replicated Pods.

For example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ai-api
  template:
    metadata:
      labels:
        app: ai-api
    spec:
      containers:
        - name: ai-api
          image: myregistry.azurecr.io/ai-api:v1
          ports:
            - containerPort: 8080

The important relationship is:

Deployment → ReplicaSets → Pods

The Deployment controller creates and manages a ReplicaSet, which in turn maintains the requested number of Pods.

If:

replicas: 3

is specified, Kubernetes attempts to maintain three Pods matching the Deployment’s selector.

If a Pod fails, Kubernetes can create a replacement.

6. Labels and Selectors

Labels are extremely important in Kubernetes.

A label identifies or categorizes a resource:

labels:
  app: ai-api

A selector determines which resources should be associated with another resource.

For example:

selector:
  matchLabels:
    app: ai-api

The Deployment’s selector must correspond to labels on its Pod template.

A Service can then use the same label:

selector:
  app: ai-api

This allows the Service to route traffic to the appropriate Pods.

Exam Tip

A common exam scenario presents a Deployment and Service that aren’t communicating.

Check the Service selector and the Pod labels.

For example:

# Pod
labels:
  app: ai-api

and:

# Service
selector:
  app: ai-api

match.

But:

selector:
  app: api

does not.

A mismatch can result in a Service with no appropriate endpoints.

7. Container Images

A Deployment specifies the image that Kubernetes should run:

containers:
  - name: ai-api
    image: myregistry.azurecr.io/ai-api:v1

For Azure-based applications, the image may be stored in Azure Container Registry (ACR).

The image reference generally contains:

<registry>/<repository>:<tag>

For example:

contosoregistry.azurecr.io/inference-api:2.1

The tag identifies the particular version of the image.

Best Practice

Avoid relying on ambiguous tags such as:

latest

for production deployments when deterministic versioning is important.

Using an explicit version such as:

inference-api:2.1.4

makes deployments easier to reproduce and troubleshoot.

8. Connecting AKS to Azure Container Registry

An AKS application frequently pulls its container images from ACR.

The AKS cluster must have appropriate permissions to pull the image.

For example, Azure CLI can be used to attach an ACR to an AKS cluster:

az aks update \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --attach-acr myRegistry

The exact identity and authorization configuration can vary depending on how the AKS cluster is configured.

The important concept is:

AKS must be authorized to pull the private container image.

If the image cannot be pulled, Pods may enter states such as:

ImagePullBackOff

or:

ErrImagePull

9. Exposing an Application with a Service

A Pod’s IP address is generally not intended to be the stable endpoint for an application.

A Kubernetes Service provides a stable network abstraction for accessing a set of Pods.

Example:

apiVersion: v1
kind: Service
metadata:
  name: ai-api
spec:
  selector:
    app: ai-api
  ports:
    - port: 80
      targetPort: 8080
  type: LoadBalancer

Here:

  • port: 80 is the Service port.
  • targetPort: 8080 is the container/application port.
  • selector: app: ai-api identifies the Pods receiving traffic.
  • type: LoadBalancer requests an externally accessible load-balancing endpoint through the cloud provider integration.

10. Service Types

The most important Service types to recognize are:

ClusterIP

type: ClusterIP

This is the default Service type.

It provides an internal cluster endpoint.

Use it when the application should be reachable from within the Kubernetes cluster but doesn’t need to be directly exposed externally.

NodePort

type: NodePort

Exposes the Service through a port on each node.

It is useful in certain scenarios but is generally less convenient than higher-level ingress or load-balancing approaches for production web applications.

LoadBalancer

type: LoadBalancer

Requests an external load balancer from the cloud provider.

In AKS, this can provide an externally reachable IP address for the application.

A newly created LoadBalancer Service may initially show:

EXTERNAL-IP   <pending>

until the Azure networking resources are provisioned.

11. Deploying a Manifest to AKS

Once kubectl is configured to communicate with the AKS cluster, the primary command for applying a manifest is:

kubectl apply -f deployment.yaml

For example:

kubectl apply -f ai-api.yaml

kubectl apply is an important command because it applies the desired configuration described by the manifest to the cluster.

Microsoft’s AKS documentation uses this pattern for deploying applications from YAML manifests.

You can also apply a directory:

kubectl apply -f ./manifests/

This is useful when an application consists of multiple YAML files.

12. Applying Multiple Resources in One File

A YAML file can contain multiple Kubernetes resources.

The resources are separated using:

---

For example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-api
spec:
  ...
---
apiVersion: v1
kind: Service
metadata:
  name: ai-api
spec:
  ...

This allows the Deployment and Service to be maintained together.

An AKS application can therefore be deployed using a single command:

kubectl apply -f ai-api.yaml

The manifest can create multiple Kubernetes objects.

13. Connecting kubectl to AKS

Before deploying an application, kubectl must be configured to communicate with the correct AKS cluster.

A common command is:

az aks get-credentials \
  --resource-group myResourceGroup \
  --name myAKSCluster

This configures the local Kubernetes client with credentials and cluster information.

You can then verify connectivity:

kubectl get nodes

If the connection is successful, the cluster’s nodes should be displayed.

Exam Tip

Know the distinction:

az aks ...

is used to manage/interact with the Azure AKS resource.

kubectl ...

is used to interact with Kubernetes resources running in the cluster.

14. Namespaces

Namespaces provide logical isolation within a Kubernetes cluster.

A manifest can specify a namespace:

metadata:
  name: ai-api
  namespace: production

Alternatively, the namespace can be supplied when using kubectl:

kubectl apply -f ai-api.yaml -n production

You can view resources in a namespace with:

kubectl get pods -n production

Namespaces are useful for separating environments or application components.

For example:

development
testing
production

can exist within the same cluster.

15. Environment Variables

Container applications often require configuration through environment variables.

A manifest can specify them directly:

env:
  - name: MODEL_NAME
    value: "my-model"
  - name: LOG_LEVEL
    value: "Information"

However, application configuration should generally be separated from the container image.

Kubernetes provides ConfigMaps for non-sensitive configuration and Secrets for sensitive information.

16. ConfigMaps

A ConfigMap stores non-sensitive configuration data.

Example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ai-config
data:
  MODEL_NAME: "my-model"
  LOG_LEVEL: "Information"

A Deployment can consume the values:

envFrom:
  - configMapRef:
      name: ai-config

This makes it possible to change configuration without rebuilding the container image.

17. Kubernetes Secrets

Sensitive information should not normally be hard-coded into a Deployment manifest.

Kubernetes Secrets can be used to store sensitive configuration such as:

  • Passwords
  • API keys
  • Connection strings
  • Certificates

For example:

env:
  - name: API_KEY
    valueFrom:
      secretKeyRef:
        name: ai-secrets
        key: api-key

For production Azure applications, you should also understand Azure-native approaches for managing secrets, such as Azure Key Vault and workload identity, rather than treating a Kubernetes Secret as equivalent to a fully managed secret-management solution.

18. Resource Requests and Limits

Containers can specify CPU and memory requests and limits.

For example:

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

Requests

A request indicates the resources needed for scheduling.

Kubernetes uses requests when determining where a Pod can run.

Limits

A limit establishes the maximum resource usage permitted for the container.

For AI workloads, resource specifications can be particularly important because inference workloads can consume substantial CPU or memory.

19. Health Probes

Kubernetes supports health probes that help determine application health.

Three important probe concepts are:

Startup probe

Determines whether an application has successfully started.

This is particularly useful for applications that take a long time to initialize.

Readiness probe

Determines whether the application is ready to receive traffic.

If a container isn’t ready, Kubernetes can prevent traffic from being sent to it through a Service.

Liveness probe

Determines whether the container is still functioning correctly.

If the liveness probe repeatedly fails, Kubernetes can restart the container.

Example:

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

Exam Distinction

Remember:

Readiness = Should this Pod receive traffic?

Liveness = Is this container still healthy enough to keep running?

Startup = Has this application finished starting?

20. Updating an Application

One of the major benefits of declarative manifests is that you can modify the desired state and apply it again.

For example, changing:

image: myregistry.azurecr.io/ai-api:v1

to:

image: myregistry.azurecr.io/ai-api:v2

and running:

kubectl apply -f ai-api.yaml

causes Kubernetes to reconcile the Deployment with the new desired configuration.

A Deployment can perform a rolling update, gradually replacing existing Pods with Pods running the new version.

This reduces application downtime compared with manually deleting all existing Pods.

21. Checking Deployment Status

After deploying a manifest, use:

kubectl get deployments

For more detailed information:

kubectl describe deployment ai-api

To inspect Pods:

kubectl get pods

To obtain additional information:

kubectl get pods -o wide

You can also watch changes:

kubectl get pods --watch

These commands are important for verifying whether the application has successfully transitioned to its desired state.

22. Viewing Application Logs

If a container is running but the application isn’t behaving correctly, inspect its logs:

kubectl logs <pod-name>

If a Pod contains multiple containers:

kubectl logs <pod-name> -c <container-name>

Logs are often the first place to look for application-level failures.

23. Using kubectl describe

When Kubernetes reports an unexpected condition, kubectl describe provides useful diagnostic information.

For example:

kubectl describe pod <pod-name>

This can reveal:

  • Scheduling problems
  • Container image errors
  • Failed probes
  • Mount failures
  • Events
  • Resource issues

For a Service:

kubectl describe service ai-api

can help identify configuration problems.

24. Common Deployment Problems

Several problems are particularly useful to recognize for the exam.

ImagePullBackOff

Usually indicates that Kubernetes cannot successfully pull the specified image.

Potential causes include:

  • Incorrect image name
  • Incorrect tag
  • Image doesn’t exist
  • Authentication/authorization failure
  • Registry connectivity issue

CrashLoopBackOff

Indicates that a container repeatedly starts and then fails.

Potential causes include:

  • Application startup failure
  • Invalid configuration
  • Missing environment variables
  • Application exception
  • Dependency failure

Start troubleshooting with:

kubectl logs <pod-name>

and:

kubectl describe pod <pod-name>

Pod stuck in Pending

A Pod may remain Pending because:

  • No node has sufficient resources
  • Node selectors don’t match available nodes
  • A required volume cannot be provisioned
  • Scheduling constraints cannot be satisfied

Inspect:

kubectl describe pod <pod-name>

for scheduling events.

Service has no endpoints

If a Service exists but isn’t routing traffic, check:

  1. Service selector
  2. Pod labels
  3. Pod readiness
  4. Service and container ports

For example:

selector:
  app: ai-api

must correspond to:

labels:
  app: ai-api

25. Managing Applications Declaratively

The major conceptual advantage of manifests is that they allow infrastructure and application configuration to be represented as code.

Instead of manually configuring a production environment, the desired configuration can be stored in source control.

For example:

/manifests
    namespace.yaml
    configmap.yaml
    deployment.yaml
    service.yaml

A deployment pipeline can then apply these manifests to an AKS cluster.

This provides:

  • Repeatability
  • Version control
  • Change tracking
  • Easier rollback
  • Consistent environments
  • Automation
  • Infrastructure-as-code characteristics

26. Manifest Files and CI/CD

Manifest files fit naturally into CI/CD processes.

A typical workflow might look like:

Developer commits code
        ↓
Build container image
        ↓
Push image to ACR
        ↓
Update Kubernetes manifest
        ↓
CI/CD pipeline
        ↓
kubectl apply
        ↓
AKS Deployment
        ↓
Rolling update

The image and Kubernetes configuration should generally be treated as separate concerns.

The container image defines the application artifact.

The Kubernetes manifest defines how that artifact should be deployed.

27. Example Complete Manifest

The following example illustrates a simplified AI inference API deployed to AKS.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: inference-api
  template:
    metadata:
      labels:
        app: inference-api
    spec:
      containers:
        - name: inference-api
          image: myregistry.azurecr.io/inference-api:1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "1"
              memory: "1Gi"
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: inference-api
spec:
  selector:
    app: inference-api
  ports:
    - port: 80
      targetPort: 8080
  type: LoadBalancer

Deploy it with:

kubectl apply -f inference-api.yaml

Then verify:

kubectl get deployments
kubectl get pods
kubectl get services

The Service can expose the application externally through an Azure load balancer.

28. Important Commands to Know

CommandPurpose
az aks get-credentialsConfigure kubectl to connect to an AKS cluster
kubectl get nodesView cluster nodes
kubectl apply -f file.yamlCreate/update resources from a manifest
kubectl get deploymentsView Deployments
kubectl get podsView Pods
kubectl get servicesView Services
kubectl describe podInspect detailed Pod information
kubectl describe deploymentInspect a Deployment
kubectl logsView container logs
kubectl get pods -o wideView Pods with additional placement/network information
kubectl delete -f file.yamlDelete resources defined by a manifest
kubectl get eventsView Kubernetes events

A particularly important distinction is:

kubectl apply -f manifest.yaml

is generally preferred for declarative management because it creates or updates the resources described by the manifest.

29. Key Exam Takeaways

For AI-200, make sure you understand these relationships:

Manifest

Defines the desired state of Kubernetes resources.

Deployment

Manages replicated Pods and supports controlled updates.

Pod

The basic execution unit containing one or more containers.

Service

Provides a stable network endpoint for a group of Pods.

Labels

Identify resources.

Selectors

Determine which resources another resource targets.

ConfigMap

Stores non-sensitive configuration.

Secret

Stores sensitive configuration within Kubernetes.

kubectl apply

Applies a declarative manifest.

ACR

Commonly stores the container images consumed by AKS.

Readiness probe

Determines whether a Pod should receive traffic.

Liveness probe

Determines whether a container should continue running.

Startup probe

Determines whether an application has successfully started.

kubectl describe

Useful for diagnosing Kubernetes resource and scheduling problems.

kubectl logs

Useful for diagnosing application/container failures.

Practice Exam Questions

Question 1

You have an AI inference application running in AKS. The application should run three identical instances, and Kubernetes should replace an instance if its Pod fails.

Which Kubernetes resource should you use?

A. Deployment

B. Service

C. ConfigMap

D. Ingress

Answer: A

Explanation

A Deployment manages replicated Pods and maintains the desired number of replicas. If a Pod managed by the Deployment fails, Kubernetes can create a replacement.

A Service provides network access to Pods but doesn’t manage their lifecycle. A ConfigMap stores configuration, and an Ingress manages HTTP/HTTPS routing.

Question 2

An AKS application has a Deployment with the following Pod label:

labels:
  app: inference-api

The application is exposed through a Service, but the Service isn’t routing traffic to the Pods.

The Service contains:

selector:
  app: ai-service

What should you change?

A. Change the Deployment’s replicas value

B. Change the Service selector to app: inference-api

C. Change the Service type to ClusterIP

D. Change the container’s containerPort

Answer: B

Explanation

The Service selector must match the labels assigned to the target Pods. The Pods are labeled:

app: inference-api

Therefore, the Service should use:

selector:
  app: inference-api

Changing the replica count or Service type does not correct the selector mismatch.

Question 3

You have modified a Kubernetes Deployment manifest to use version 2 of an AI inference container:

image: myregistry.azurecr.io/inference-api:v2

What command should you normally use to apply the change?

A. kubectl restart deployment

B. kubectl create deployment

C. kubectl apply -f deployment.yaml

D. az aks update --image v2

Answer: C

Explanation

kubectl apply -f applies the desired state represented by the manifest. When the Deployment’s Pod template changes, Kubernetes can perform a rolling update to replace Pods running the previous image.

Question 4

An AI API deployed to AKS takes several minutes to initialize because it loads a large machine-learning model. Kubernetes is restarting the container before initialization completes.

Which configuration is most appropriate?

A. Increase the Service’s targetPort

B. Add a startup probe

C. Add a ConfigMap

D. Change the Service to LoadBalancer

Answer: B

Explanation

A startup probe is designed for applications that require significant time to initialize. It allows Kubernetes to determine when startup has completed before normal liveness checking takes effect.

A readiness probe controls whether traffic should be sent to the application, while a startup probe is specifically useful during initialization.

Question 5

An AKS Deployment has been created, but its Pods remain in the Pending state.

Which command is most useful for investigating scheduling-related events for a specific Pod?

A. kubectl describe pod <pod-name>

B. kubectl logs <pod-name>

C. kubectl get service <service-name>

D. kubectl apply -f deployment.yaml

Answer: A

Explanation

kubectl describe pod provides detailed information about the Pod, including Kubernetes events. These events can reveal issues such as insufficient resources, unsatisfied scheduling constraints, or volume problems.

kubectl logs is more useful when a container has started and is producing application logs.

Question 6

You want an application in AKS to be reachable from outside the cluster using an Azure-provided external load balancer.

Which Service type should you specify?

A. ClusterIP

B. ExternalName

C. NodePort

D. LoadBalancer

Answer: D

Explanation

A Service with:

type: LoadBalancer

requests an external load balancer through the cloud provider integration. In AKS, this can provide an externally reachable IP address.

ClusterIP is primarily for internal cluster access.

Question 7

An AI application requires the following configuration:

MODEL_NAME=customer-support-model
LOG_LEVEL=Information

The values are not sensitive and should be changed independently of the container image.

Which Kubernetes resource is most appropriate?

A. Secret

B. ConfigMap

C. Deployment replica

D. Service

Answer: B

Explanation

A ConfigMap is designed to store non-sensitive configuration data separately from the application container image.

A Kubernetes Secret is intended for sensitive information such as credentials and keys.

Question 8

You have successfully deployed an AKS application, but the Pods show ImagePullBackOff.

The Deployment specifies:

image: myregistry.azurecr.io/inference-api:v5

Which is the most likely category of problem?

A. The Service selector doesn’t match the Pod labels

B. The readiness probe is failing

C. AKS cannot successfully retrieve the specified container image

D. The Deployment has too many replicas

Answer: C

Explanation

ImagePullBackOff indicates that Kubernetes is having difficulty pulling the container image. Potential causes include an incorrect image name or tag, an image that doesn’t exist, or insufficient authorization to access a private registry.

Service selectors and readiness probes are unrelated to the initial image-pull operation.

Question 9

You want an AKS application to receive traffic only after its /health endpoint indicates that it is ready.

Which probe should you configure?

A. Readiness probe

B. Liveness probe

C. Startup probe

D. Resource probe

Answer: A

Explanation

A readiness probe determines whether a container is ready to receive traffic. If the readiness probe fails, Kubernetes can keep the Pod out of the Service’s ready endpoints.

A liveness probe determines whether a container should continue running, while a startup probe is intended to determine whether a slow-starting application has completed initialization.

Question 10

An AKS application is deployed from a YAML file containing both a Deployment and a Service separated by ---.

Which command can be used to create or update both resources according to the manifest?

A. kubectl get -f application.yaml

B. kubectl logs -f application.yaml

C. kubectl describe -f application.yaml

D. kubectl apply -f application.yaml

Answer: D

Explanation

kubectl apply -f processes the resources defined in the manifest and creates or updates them to match the desired state.

The --- separator allows multiple Kubernetes resource definitions to be included in the same YAML file.

Final Review

For this AI-200 topic, the most important thing is to understand how a declarative Kubernetes manifest translates into a running application on AKS.

The core flow is:

Container image
      ↓
Azure Container Registry
      ↓
Kubernetes Deployment manifest
      ↓
kubectl apply
      ↓
Deployment
      ↓
ReplicaSet
      ↓
Pods
      ↓
Service
      ↓
Application endpoint

When troubleshooting, think systematically:

Can't deploy?
    ↓
Can AKS pull the image?
    ↓
Is the Pod scheduled?
    ↓
Is the container starting?
    ↓
Are startup/readiness/liveness probes correct?
    ↓
Do Service selectors match Pod labels?
    ↓
Are ports configured correctly?

If you understand that flow—and can recognize Deployment vs. Pod vs. Service vs. ConfigMap vs. Secret, along with the purpose of kubectl apply, labels/selectors, probes, and common Pod states—you will have a strong foundation for the manifest-based AKS questions in AI-200.

Go to the AI-200 Exam Prep Hub main page

AI-200, azure, Cloud computing, Microsoft Certification

Build, Store, Version, and Manage Container Images by Using Azure Container Registry (AI-200 Exam Prep)

 
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, store, version, and manage container images by using Azure Container Registry

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 (ACR) is a managed, private registry service in Azure for storing and managing container images and other OCI-compatible artifacts. It provides a central location from which containerized applications can obtain the images they need to run on services such as Azure App Service, Azure Container Apps, Azure Kubernetes Service (AKS), and Azure Container Instances.

For the AI-200: Developing AI Cloud Solutions on Azure exam, you should understand more than simply how to push an image into ACR. You should be comfortable with the hierarchy of registries, repositories, images, tags, manifests, and layers; image versioning strategies; building images using ACR Tasks; managing and deleting images; and selecting appropriate authentication and registry capabilities.

The current Microsoft Learn study guide specifically identifies this objective as part of Implement container application hosting. It also separately identifies ACR Tasks as an exam objective, so understanding how ACR stores images and how ACR Tasks builds them is particularly important.

1. What Is Azure Container Registry?

Azure Container Registry is a private container registry service hosted in Azure.

A container registry solves a fundamental problem in containerized application development:

Where do applications securely obtain the container images they need to run?

Instead of relying exclusively on a public registry, an organization can maintain its own private registry in Azure.

A typical workflow looks like this:

Developer
    |
    | Build container image
    v
Docker / ACR Tasks
    |
    | Push
    v
Azure Container Registry
    |
    +------------------+
    |                  |
    v                  v
Azure App Service     AKS
    |                  |
    v                  v
Container Apps       Container workloads

ACR provides capabilities for:

  • Storing container images
  • Storing OCI artifacts
  • Organizing images into repositories
  • Tagging and versioning images
  • Pushing and pulling images
  • Building images using ACR Tasks
  • Managing image metadata
  • Controlling access
  • Replicating images across regions
  • Integrating with Azure container services

Microsoft describes ACR as a private, managed registry that supports building, storing, and managing images for container deployments.

2. Understand the ACR Hierarchy

One of the most important concepts for AI-200 is understanding how ACR organizes container content.

The hierarchy can be thought of as:

Azure Container Registry
        |
        +-- Repository
        |      |
        |      +-- Image : Tag
        |      +-- Image : Tag
        |      +-- Image : Tag
        |
        +-- Repository
               |
               +-- Image : Tag
               +-- Image : Tag

The important concepts are:

  1. Registry
  2. Repository
  3. Artifact/Image
  4. Tag
  5. Manifest
  6. Layer
  7. Digest

Understanding the distinctions between these concepts is a common source of exam questions.

2.1 Registry

The registry is the overall ACR resource.

For example:

contosoregistry.azurecr.io

The registry provides the endpoint through which clients push and pull container images.

A registry can contain many repositories.

2.2 Repository

A repository is a collection of related container images or artifacts.

For example:

contosoregistry.azurecr.io/customer-api

The repository could contain:

customer-api:v1
customer-api:v2
customer-api:v3

Repositories can also use namespaces:

contosoregistry.azurecr.io/marketing/campaign-api:v2

Namespaces help organize repositories logically, although they aren’t independent Azure resources or hierarchical security boundaries simply because they contain / characters.

Microsoft notes that repository names can include namespaces and are managed independently by the registry.

3. Container Image Tags

A tag provides a human-readable identifier for a particular version or variant of an image.

For example:

customer-api:v1
customer-api:v2
customer-api:2026-08-07
customer-api:production

The complete image reference might be:

contosoregistry.azurecr.io/customer-api:v2

The structure is:

<registry>/<repository>:<tag>

For example:

contosoregistry.azurecr.io/customer-api:v2

where:

ComponentValue
Registrycontosoregistry.azurecr.io
Repositorycustomer-api
Tagv2

Microsoft recommends using appropriate tagging strategies for deployment scenarios and notes that latest is used by default when no tag is specified in Docker commands.

4. Tagging and Versioning Strategies

Image versioning is extremely important for reliable deployments.

Consider:

customer-api:latest

This tag is convenient, but it does not necessarily identify an immutable version.

Suppose today’s latest points to:

Image A

and tomorrow the same tag is updated:

latest → Image B

A deployment configured to use latest may therefore receive a different image without its configuration changing.

For production deployments, a better approach is generally to use unique version identifiers.

Examples:

customer-api:v1.0.0
customer-api:v1.1.0
customer-api:v1.2.0

or:

customer-api:20260807.1
customer-api:20260807.2

or a source-control commit identifier:

customer-api:a81f42c

A useful pattern is:

latest       → convenient development/testing reference
v1.4.2       → human-readable release
a81f42c      → unique build identifier

Exam Tip

If a question asks how to ensure that a deployment consistently uses a specific image version, be cautious about answers using:

:latest

A unique tag or, even more strongly, an image digest provides better version specificity.

5. Image Digests

Container images are also identified by a digest.

For example:

contosoregistry.azurecr.io/customer-api@sha256:abc123...

A digest identifies the content associated with a manifest.

Compare:

customer-api:v2

with:

customer-api@sha256:abc123...

A tag can be moved to point to another image.

A digest identifies a specific content-addressed version.

Microsoft specifically notes that pulling by digest guarantees the image version being retrieved even if an identically tagged image is subsequently pushed.

Exam Tip

Remember:

Tag = human-friendly version reference

Digest = content-addressed, precise image reference

6. Container Image Layers

Container images consist of one or more layers.

Dockerfiles commonly create multiple layers.

For example:

FROM python:3.12
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY app.py .

The resulting image is composed of layers.

One of the advantages of layers is reuse.

If two images share the same base layers, those layers don’t necessarily have to be independently stored and transferred each time.

This can reduce storage and transfer requirements.

7. Manifests

A container image is associated with a manifest.

The manifest contains information needed to identify the image and its layers.

Conceptually:

Image Manifest
      |
      +-- Configuration
      |
      +-- Layer 1
      +-- Layer 2
      +-- Layer 3

The manifest is also associated with the image’s digest.

This distinction matters when managing images in ACR.

For example, removing a tag doesn’t necessarily mean that all image data is immediately removed.

An untagged manifest and its associated layers may continue to consume storage until they are deleted and no longer referenced.

Microsoft specifically warns that repeatedly pushing modified artifacts with identical tags can create untagged artifacts that continue consuming registry storage.

8. Pushing an Image to ACR

A common workflow is:

Step 1: Build the image

docker build -t customer-api:v1 .

Step 2: Tag the image with the ACR login server

docker tag customer-api:v1 \
    contosoregistry.azurecr.io/customer-api:v1

Step 3: Authenticate to ACR

az acr login --name contosoregistry

Step 4: Push the image

docker push \
    contosoregistry.azurecr.io/customer-api:v1

The image is now stored in:

contosoregistry.azurecr.io/customer-api

with the tag:

v1

9. Pulling an Image

A client can pull the image by tag:

docker pull \
    contosoregistry.azurecr.io/customer-api:v1

Or by digest:

docker pull \
    contosoregistry.azurecr.io/customer-api@sha256:<digest>

The second approach provides stronger guarantees regarding exactly which image content is retrieved.

10. Azure Container Registry Tasks

One of the most important ACR features for AI-200 is ACR Tasks.

ACR Tasks allows container images to be built in Azure rather than requiring the developer to perform the build locally.

Microsoft describes ACR Tasks as a suite of capabilities for building, testing, and managing container images.

For example:

az acr build \
    --registry contosoregistry \
    --image customer-api:v1 \
    --file Dockerfile .

The command:

  1. Sends the build context to Azure.
  2. Uses the Dockerfile.
  3. Builds the image in Azure.
  4. Tags the resulting image.
  5. Pushes the resulting image into the registry.

This is particularly useful when a developer doesn’t have Docker installed locally.

Microsoft’s current quickstart explicitly demonstrates building, pushing, and running an image using ACR Tasks without requiring a local Docker installation.

11. ACR Tasks Quick Tasks

A quick task is useful for an on-demand image build.

For example:

az acr build \
    --registry contosoregistry \
    --image customer-api:v1 \
    .

This is useful during the development inner loop.

Instead of:

Developer machine
    |
    +-- docker build
    +-- docker tag
    +-- docker push

you can use:

Developer
    |
    | az acr build
    v
Azure
    |
    +-- Build
    +-- Tag
    +-- Push
    v
ACR

12. Automated ACR Tasks

ACR Tasks can also be configured to automatically execute when certain events occur.

For example:

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

ACR Tasks can also respond to base image updates.

For example, suppose an application uses:

FROM python:3.12

A base-image update can trigger an ACR Task to rebuild the application image.

This is useful for keeping application images current when their base images change.

Microsoft documents ACR Tasks triggers for Git commits and base-image updates.

13. Multi-Step ACR Tasks

ACR Tasks can execute more sophisticated workflows.

For example:

Build application image
        |
        v
Run application
        |
        v
Run test container
        |
        v
Push image

Multi-step tasks are defined using YAML.

A simplified example is:

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

ACR Tasks supports three major step types:

StepPurpose
buildBuild a container image
pushPush an image to a registry
cmdRun a container as a command

Exam Tip

If a question describes a workflow that needs to build, test, and push multiple containers, think:

ACR Tasks multi-step task

14. ACR Tasks and External Registries

ACR Tasks can also interact with other registries.

For example, a task may need to:

ACR
 |
 +-- Pull base image from another registry
 |
 +-- Build application
 |
 +-- Push application image to ACR

Credentials can be configured for tasks when access to another registry is required.

For more secure scenarios, ACR Tasks can use managed identities to access protected Azure resources without embedding credentials directly in task definitions.

15. Authentication to Azure Container Registry

ACR is generally private, so clients need appropriate authentication and authorization to access it.

Common authentication approaches include:

  • Microsoft Entra identities
  • Managed identities
  • Service principals
  • Administrator credentials
  • Repository-scoped access mechanisms
  • Anonymous pull, where explicitly configured and supported

Microsoft’s documentation emphasizes that ACR operations such as push and pull require authentication unless anonymous pull is enabled.

16. Managed Identity and ACR

Managed identities are particularly important in Azure-native applications.

Suppose an AKS cluster needs to pull an image:

AKS
 |
 | Managed Identity
 v
Azure Container Registry
 |
 v
customer-api:v1

Rather than storing a registry password in application configuration, the Azure resource can use a managed identity and appropriate permissions.

For a non-ABAC-enabled registry, a common pull-only role is:

AcrPull

For push and pull:

AcrPush

For ABAC-enabled registries, Microsoft documents repository-scoped roles such as:

Container Registry Repository Reader
Container Registry Repository Writer

The exact role depends on the registry’s authorization model.

Exam Tip

When the question says:

“An Azure service needs to pull images from ACR without storing credentials.”

Think:

Managed identity + appropriate ACR permissions

17. ACR Pricing Tiers

Azure Container Registry currently provides three pricing tiers:

  • Basic
  • Standard
  • Premium

The tiers provide increasing capacity and capabilities.

CapabilityBasicStandardPremium
Intended useLower-volume scenariosProduction scenariosHigh-volume/advanced scenarios
Included storage10 GiB100 GiB500 GiB
Geo-replicationNoNoYes
Private endpointsNoNoYes
Content trustNoNoYes
Customer-managed keysNoNoYes
Dedicated Tasks agent poolsNoNoYes
Higher throughput/concurrencyLowerMediumHigher

All three tiers provide core registry capabilities, while Premium adds advanced capabilities and higher limits.

Important Exam Distinction

If the requirement is:

“Replicate a registry across multiple Azure regions.”

Think:

Premium ACR

Geo-replication is a Premium feature.

18. Geo-Replication

Geo-replication allows an ACR to replicate its content across multiple Azure regions.

For example:

                 Azure Container Registry
                          |
             +------------+------------+
             |                         |
             v                         v
         East US                  West Europe
        Geo-replica               Geo-replica
             |                         |
             v                         v
          AKS US                  AKS Europe

When an image is pushed to the geo-replicated registry, its content is synchronized to the configured replicas.

The advantage is that applications can access images from regions closer to where they run.

Microsoft describes geo-replication as providing a single registry management experience while synchronizing content across selected regions.

Don’t confuse:

Availability zones and geo-replication.

Availability zones provide resilience across zones within a region.

Geo-replication distributes registry content across different Azure regions.

Current Microsoft documentation states that zone redundancy is enabled by default for ACR registries in supported regions across Basic, Standard, and Premium tiers.

19. Managing Images and Repositories

You can manage repositories and images through:

  • Azure portal
  • Azure CLI
  • REST APIs
  • SDKs
  • Docker/OCI tooling

For example, you can list repositories:

az acr repository list \
    --name contosoregistry \
    --output table

List tags:

az acr repository show-tags \
    --name contosoregistry \
    --repository customer-api \
    --output table

You can also inspect manifests and image metadata.

The Azure portal exposes repositories and their image tags through the registry’s Repositories interface.

20. Deleting Images

Suppose a repository contains:

customer-api:v1
customer-api:v2
customer-api:v3

You can remove an image tag using Azure CLI.

For example:

az acr repository untag \
    --name contosoregistry \
    --image customer-api:v1

However, remember an important distinction:

Untagging an image does not necessarily immediately remove the underlying image data.

The manifest may become untagged while its layers continue consuming storage.

Microsoft specifically warns about the accumulation of untagged artifacts when images are repeatedly pushed using the same tags.

21. Retention of Untagged Manifests

ACR supports a retention policy for untagged manifests.

The purpose is to automatically remove untagged manifests after a configured period.

For example:

Image:v1
Image:v2
Image:v3

If v2 is removed:

Image:v2 → untagged manifest

A retention policy can eventually remove the untagged manifest.

The current Microsoft documentation identifies the untagged-manifest retention policy as a Premium feature and currently documents it as a preview feature. The policy can be configured for a retention period from 0 through 365 days.

Important Warning

If an application relies on pulling an image by its digest, automatically deleting untagged manifests can make that image unavailable.

This is an important operational consideration and a potential exam scenario.

22. Image Tagging Best Practices

A strong production tagging strategy should make image identification predictable.

A useful approach is to use multiple tags for different purposes.

For example:

customer-api:v2.4.1
customer-api:build-1847
customer-api:a81f42c

You might also maintain:

customer-api:production

as a deployment-oriented alias.

However, don’t rely on a mutable tag such as production or latest when you require immutable deployment behavior.

A good pattern is:

Human-readable release
        +
Unique build identifier
        +
Optional environment alias

For example:

customer-api:v2.4.1
customer-api:build-1847
customer-api:production

The production deployment can ultimately be pinned to a specific immutable image reference/digest.

23. Common ACR Mistakes

Mistake 1: Using latest for production deployments

latest can change.

Better: use unique version tags and/or digests.

Mistake 2: Assuming deleting a tag deletes the image immediately

An untagged manifest may continue consuming storage.

Better: understand manifests, layers, untagging, deletion, and retention.

Mistake 3: Giving every workload push permissions

An application that only needs to run an image generally doesn’t need permission to push images.

Better: follow least privilege.

For example:

Application → AcrPull
Build pipeline → AcrPush

Mistake 4: Storing registry passwords in application code

This creates unnecessary credential-management risks.

Better: use managed identities or another appropriate identity mechanism.

Mistake 5: Choosing Premium solely because it sounds better

Premium should be selected because its capabilities are required.

Examples include:

  • Geo-replication
  • Private endpoints
  • Content trust
  • Higher throughput
  • Advanced networking
  • Dedicated Tasks agent pools

Mistake 6: Confusing ACR with ACR Tasks

They are related but different concepts.

ACR:

Stores and manages container images.

ACR Tasks:

Builds, tests, and automates container image workflows.

A single ACR resource can therefore be used to store images while ACR Tasks provides the automation to build those images.

24. Important AI-200 Concepts to Know

For this exam objective, make sure you can explain the following without referring to documentation:

ConceptWhat you should know
Azure Container RegistryManaged private container registry
RegistryTop-level ACR resource
RepositoryCollection of related images/artifacts
TagHuman-readable image/version reference
DigestContent-addressed image reference
ManifestDescribes image/artifact and its layers
LayerComponent of a container image
az acr loginAuthenticates a client to ACR
docker pushUploads an image to ACR
docker pullDownloads an image from ACR
az acr buildBuilds an image using ACR Tasks
ACR TasksCloud-based image build/test automation
Multi-step taskBuild/test/push workflows using YAML
AcrPullPull permission for applicable non-ABAC registry scenarios
AcrPushPush/pull permission for applicable non-ABAC registry scenarios
Managed identityCredential-free Azure resource authentication
BasicEntry-level ACR tier
StandardHigher capacity production-oriented tier
PremiumAdvanced capabilities such as geo-replication/private endpoints
Geo-replicationReplicate registry content across regions
Retention policyAutomatically remove eligible untagged manifests

25. AI-200 Scenario Patterns to Recognize

The exam is likely to test your ability to choose the appropriate Azure capability based on a scenario.

Scenario: Build without Docker locally

Requirement: Developers don’t have Docker installed.

Answer: ACR Tasks / az acr build.

Scenario: Automatically rebuild after a Git commit

Requirement: Every source-code commit should trigger an image build.

Answer: ACR Task with a source-code trigger.

Scenario: Rebuild after base image updates

Requirement: Automatically rebuild application images when their base image changes.

Answer: ACR Tasks base-image trigger.

Scenario: Run the same image in several Azure regions

Requirement: Applications in multiple regions should access registry content efficiently.

Answer: ACR Premium with geo-replication.

Scenario: Application only needs to pull images

Requirement: A workload should retrieve images but shouldn’t be able to modify them.

Answer: Grant an appropriate pull-only role, such as AcrPull where applicable, or the appropriate repository reader role for an ABAC-enabled registry.

Scenario: Avoid credentials in application configuration

Requirement: An Azure-hosted application needs to access ACR without storing passwords.

Answer: Managed identity + appropriate registry permissions.

Scenario: Guarantee a specific image

Requirement: A deployment must always retrieve exactly the same image content.

Answer: Use an image digest rather than relying solely on a mutable tag.

26. Quick Review

The following mental model is useful for the exam:

                    AZURE CONTAINER REGISTRY
                             |
             +---------------+---------------+
             |                               |
        Repositories                    ACR Tasks
             |                               |
      +------+------+                  Build/Test/Push
      |             |
   Image          Image
      |             |
    Tags          Tags
      |             |
   Manifest      Manifest
      |
    Layers

And remember the major distinction:

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

For production deployments:

Avoid:
    :latest
Prefer:
    :v2.4.1
    :build-1847
    @sha256:<digest>

For authentication:

Azure workload
      |
      | Managed Identity
      v
     ACR
      |
      | Appropriate least-privilege role
      v
    Pull image

For global deployments:

ACR Premium
     |
     +---- Region 1
     |
     +---- Region 2
     |
     +---- Region 3

Practice Exam Questions

Question 1

A development team has a Dockerfile and wants to build a container image directly in Azure. Developers should not need Docker installed on their local computers. The resulting image should be pushed to Azure Container Registry.

Which Azure capability should you use?

A. Azure Container Registry Tasks

B. Azure App Service deployment slots

C. Azure Container Apps revisions

D. Azure Kubernetes Service Jobs

Answer: A

Explanation: Azure Container Registry Tasks can build container images in Azure using a Dockerfile. The az acr build command provides an on-demand build capability and can push the resulting image to ACR. A local Docker installation isn’t required for this workflow.

Question 2

An application image is stored as:

contosoregistry.azurecr.io/orders:v4

What does v4 represent?

A. The registry name

B. The image tag

C. The image digest

D. The repository namespace

Answer: B

Explanation: In an image reference such as:

registry/repository:tag

the portion after the colon is the tag. Therefore, v4 is the image tag. Tags are commonly used to identify image versions.

Question 3

A production application must always retrieve exactly the same container image content. Developers are concerned that a tag could later be reassigned to a different image.

Which image reference should the application use?

A. :latest

B. :production

C. :stable

D. @sha256:<digest>

Answer: D

Explanation: Tags can be moved to different image versions. A digest is a content-addressed identifier and can be used to pull a specific image version. Microsoft specifically identifies digest-based pulls as a way to guarantee the image version being retrieved.

Question 4

An organization deploys applications to Azure regions in North America and Europe. The organization wants container images to be replicated to both regions while maintaining a single ACR management experience.

Which ACR capability should be used?

A. Repository namespaces

B. Availability zones

C. Geo-replication

D. Image tags

Answer: C

Explanation: ACR geo-replication synchronizes registry content across selected Azure regions while allowing the organization to manage the registry as a single logical registry. Geo-replication is a Premium ACR capability.

Question 5

An AKS workload needs to pull private container images from ACR. The organization does not want to store registry passwords in Kubernetes configuration.

Which approach is most appropriate?

A. Use a managed identity with appropriate ACR permissions

B. Store the ACR administrator password in the container image

C. Make the repository publicly accessible

D. Embed an ACR password in the application source code

Answer: A

Explanation: Azure resources can use managed identities to authenticate to ACR without storing credentials in application code or configuration. The identity must be granted the appropriate pull permissions.

Question 6

A development team wants an automated container workflow that performs the following:

  1. Builds an application image.
  2. Runs a test container.
  3. Builds another image.
  4. Pushes the resulting images.

Which ACR capability should the team use?

A. ACR repository namespaces

B. ACR multi-step Tasks

C. ACR geo-replication

D. ACR anonymous pull

Answer: B

Explanation: ACR Tasks supports multi-step workflows using YAML. The workflow can build, run/test, and push one or more images. The available step types include build, push, and cmd.

Question 7

An organization repeatedly pushes new builds using the same image tag. After several months, the registry contains significant amounts of storage that cannot be explained by the currently tagged images.

What is the most likely explanation?

A. ACR automatically creates a new repository for every push

B. Geo-replication is duplicating every image within the same region

C. Previous manifests became untagged while their image data remained in the registry

D. ACR stores every Dockerfile indefinitely

Answer: C

Explanation: Repeatedly pushing modified images using the same tag can result in previous manifests becoming untagged. Their layers can continue consuming registry storage until the underlying content is deleted.

Question 8

A company needs to automatically rebuild its application container whenever a new version of the application’s base container image becomes available.

Which capability should be configured?

A. Azure App Service deployment slots

B. ACR geo-replication

C. ACR repository tagging

D. An ACR Task with a base-image update trigger

Answer: D

Explanation: ACR Tasks can automatically trigger builds when a base image is updated. This is useful for rebuilding application images when their underlying base images change.

Question 9

An organization requires private connectivity to its Azure Container Registry through Azure Private Link. Which ACR pricing tier supports this capability?

A. Premium

B. Basic

C. Standard

D. All three tiers

Answer: A

Explanation: Azure Container Registry Premium supports private endpoints through Private Link. Basic and Standard do not provide this capability according to the current ACR SKU documentation.

Question 10

An administrator removes the v1 tag from an image in an ACR repository. The administrator assumes that the underlying image data has immediately been removed from the registry.

Which statement is correct?

A. Removing a tag always immediately deletes every associated layer

B. Removing a tag converts the image automatically into a public image

C. Removing a tag deletes the entire repository

D. The manifest can become untagged while its data continues consuming storage

Answer: D

Explanation: Removing a tag can leave the manifest untagged while its associated data remains in the registry. Untagged artifacts can continue consuming storage until they are deleted. ACR provides mechanisms such as retention policies for eligible untagged manifests.

Final AI-200 Takeaways

For this particular AI-200 objective, concentrate on these distinctions:

Azure Container Registry

Store and manage container images and artifacts.

ACR repository

Organizes related images.

Tag

Human-readable version/reference that can be reassigned.

Digest

Content-addressed identifier for a specific image version.

Manifest

Describes the image/artifact and its layers.

ACR Tasks

Build, test, and automate container image workflows.

az acr build

Perform an on-demand cloud-based container build.

Multi-step ACR Task

Build/test/push multiple images or perform multi-stage workflows.

Managed identity

Authenticate Azure workloads to ACR without managing passwords.

AcrPull

Pull permission for applicable non-ABAC registry scenarios.

AcrPush

Push/pull permission for applicable non-ABAC registry scenarios.

Premium

Required for capabilities such as geo-replication and private endpoints.

Geo-replication

Replicate registry content across Azure regions.

Retention

Help clean up eligible untagged manifests.

The most important exam mindset is to distinguish where the image is stored, how it is identified, how it is built, and how the workload is authorized to retrieve it. Those four dimensions—registry/repository, tag/digest, ACR Tasks, and authentication/RBAC—cover a large portion of the practical knowledge behind this objective.

Go to the AI-200 Exam Prep Hub main page