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:

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

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