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
      --> Monitor and troubleshoot solutions on AKS and Container Apps by inspecting logs, events, and end-to-end connectivity

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

Modern AI applications frequently run as distributed containerized solutions. A typical application might include several containers, APIs, background workers, databases, messaging services, and external Azure services. When something goes wrong, determining where the problem exists is often more difficult than identifying that a problem exists.

For the AI-200 exam, developers should understand how to troubleshoot applications running on:

• Azure Kubernetes Service (AKS)
• Azure Container Apps
• The networking and services that connect application components
• Azure monitoring and logging capabilities

A particularly important skill is knowing how to work from the application outward:

Application/container → Pod or replica → Service/ingress → Network → Destination

This approach helps isolate whether a problem is caused by the application itself, the container runtime, Kubernetes configuration, service discovery, ingress, networking, or an external dependency.

1. The Troubleshooting Mindset

When an application is failing, avoid immediately changing configuration. First determine which layer is failing.

A useful troubleshooting sequence is:

1. Is the application running?
2. Is the container healthy?
3. Are there useful application logs?
4. Are there Kubernetes or platform events indicating a problem?
5. Can the application communicate with its immediate dependency?
6. Can the service route traffic to the application?
7. Can traffic enter or leave the application environment?
8. Is the external dependency itself healthy?

For AKS, Microsoft recommends an inside-out approach for connectivity problems: begin with the pod and application, then work outward through the service and networking layers toward the client or destination.

This approach is particularly useful on the exam because a scenario may provide several symptoms but only one layer is actually responsible for the failure.

2. Logs vs. Events vs. Metrics

One of the most important distinctions to understand is the difference between logs, events, and metrics.

Logs

Logs are particularly useful when the application itself knows why it failed.

Examples include:

• Database connection failures
• Authentication errors
• Exceptions
• Invalid configuration
• Failed API calls
• Application startup errors

Events

Events are especially useful when Kubernetes or the hosting platform is having difficulty creating, scheduling, starting, or managing a workload.

Examples include:

• Failed scheduling
• Failed image pulls
• Container creation failures
• Probe failures
• Pod restarts
• Resource constraints

Metrics

Metrics help identify patterns rather than individual failures.

Examples include:

• CPU utilization
• Memory utilization
• Request rate
• Replica count
• Network traffic
• Latency
• Restart counts

A common exam scenario is:

An application is slow and occasionally unavailable.

Logs may identify the immediate application error, while metrics may reveal that CPU or memory is saturated and events may reveal that pods are being restarted.

You often need all three signals to understand the complete problem.

3. Monitoring and Troubleshooting AKS

AKS provides Kubernetes-native troubleshooting capabilities together with Azure monitoring services.

Important tools include:

• kubectl get
• kubectl describe
• kubectl logs
• kubectl exec
• kubectl get events
• Azure Monitor
• Container insights
• Azure portal
• Application logs
• Kubernetes events
• Metrics

4. Start by Checking Pod Status

The first question is simple:

Is the workload actually running?

Use:

kubectl get pods

For a specific namespace:

kubectl get pods -n <namespace>

To see pods across all namespaces:

kubectl get pods -A

You might see states such as:

• Running
• Pending
• Succeeded
• Failed
• CrashLoopBackOff
• ImagePullBackOff
• ErrImagePull
• ContainerCreating
• Terminating

These statuses provide an initial indication of where to investigate.

Example

Suppose you see:

NAME                         READY   STATUS             RESTARTS
ai-worker-7f4b8c9d8-x2k4m   0/1     CrashLoopBackOff   8

The pod is repeatedly starting and failing.

The next step should generally be to investigate the pod rather than immediately examining the network.

5. Use kubectl describe to Examine Resource Details and Events

Use:

kubectl describe pod <pod-name>

Or:

kubectl describe pod <pod-name> -n <namespace>

kubectl describe provides detailed information about the Kubernetes object, including its configuration, status, conditions, and associated events.

This is particularly useful for identifying problems such as:

• Failed scheduling
• Image pull failures
• Insufficient resources
• Failed health probes
• Volume mount problems
• Container startup problems

For example, an event such as:

Failed to pull image

points toward an image or registry problem rather than an application networking problem.

Likewise:

FailedScheduling

suggests that Kubernetes cannot place the pod on an appropriate node.

6. Kubernetes Events

Kubernetes events record significant activities involving Kubernetes resources.

Examples include:

• Pod scheduling
• Container creation
• Container startup
• Image pulling
• Failed scheduling
• Probe failures
• Resource-related problems

You can list events with:

kubectl get events

For a namespace:

kubectl get events -n <namespace>

Events can also be sorted or filtered when investigating a particular problem.

Kubernetes events are extremely useful for troubleshooting, but they are not intended to be a permanent application log store. By default, Kubernetes events have limited retention; current Azure documentation notes that events are available for approximately one hour unless longer-term collection is configured through monitoring capabilities such as Container insights.

Exam Tip

If a question asks:

“Which tool should you use to determine why a pod failed to start?”

Think:

kubectl describe pod and Kubernetes events

If the question asks:

“What did the application itself report?”

Think:

container logs

7. Inspect Container Logs in AKS

Use:

kubectl logs <pod-name>

For a specific namespace:

kubectl logs <pod-name> -n <namespace>

For a particular container in a multi-container pod:

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

This is especially useful when:

• The application starts and then crashes
• The application throws an exception
• A dependency cannot be reached
• Configuration is invalid
• Authentication fails
• The application is returning errors

8. Inspect Logs from a Previous Container Instance

This is an important troubleshooting technique.

If a container has crashed and restarted, its current log may not contain the information from the previous instance.

Use:

kubectl logs <pod-name> --previous

For a particular container:

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

This is particularly valuable when diagnosing:

• CrashLoopBackOff
• Startup failures
• Unexpected application termination
• Configuration errors during initialization

Exam Scenario

A pod repeatedly restarts. The current container appears healthy, but you need to determine why the previous instance terminated.

The appropriate command is:

kubectl logs <pod-name> --previous

9. Kubernetes Health Probes

Health probes are another major source of troubleshooting information.

Kubernetes supports:

Liveness probe

Determines whether a container is still functioning.

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

Readiness probe

Determines whether the application is ready to receive traffic.

A container can be running but not ready.

Startup probe

Provides additional time for applications that require significant startup time before liveness/readiness checks should begin.

Why Probes Matter

Consider an AI inference service that requires 60 seconds to load a model.

If its liveness probe begins failing after only 10 seconds, Kubernetes may repeatedly restart the container before the model finishes loading.

The result can be:

CrashLoopBackOff

even though the application itself is not fundamentally broken.

Therefore, when investigating repeated restarts, inspect:

kubectl describe pod <pod-name>

and look for probe-related events.

10. Inspect AKS Services

A pod’s IP address is generally not the endpoint that clients should depend on.

Kubernetes Services provide stable networking for workloads.

List services:

kubectl get svc

Describe a service:

kubectl describe svc <service-name>

You should investigate:

• Service type
• Port
• Target port
• Selector
• Cluster IP
• Endpoints
• Associated pods

A common failure is a Service selector that does not match the labels on the intended pods.

For example, a Service might select:

selector:
  app: ai-api

while the pods actually have:

labels:
  app: ai-service

The pods may be healthy, but the Service has no appropriate endpoints.

11. Check Service Endpoints

One of the most important connectivity checks is determining whether a Service actually has endpoints.

For example:

kubectl get endpoints <service-name>

Depending on the Kubernetes version and configuration, EndpointSlices can also be examined:

kubectl get endpointslices

If the Service has no usable endpoints, traffic cannot be routed to the expected application pods.

This creates an important troubleshooting distinction:

Pod is healthy ≠ Service is correctly routing traffic

12. Test Connectivity from Inside the Cluster

When troubleshooting network connectivity, testing from inside the cluster can eliminate several variables.

For example, you can run a temporary diagnostic pod and test connectivity to another service.

Useful tools can include:

nslookup <service-name>

curl http://<service-name>:<port>

or:

nc -z -v <host> <port>

The exact tools available depend on the container image.

This allows you to determine whether:

• DNS resolution works
• The destination port is reachable
• The service responds
• The application is actually listening

13. End-to-End AKS Connectivity Troubleshooting

Consider this architecture:

Internet
   |
   v
Ingress / Load Balancer
   |
   v
Kubernetes Service
   |
   v
Pod
   |
   v
Application
   |
   v
External Azure Service

A useful troubleshooting process is to work through the architecture one layer at a time.

Step 1: Is the pod running?

kubectl get pods

Step 2: Is the application healthy?

kubectl logs <pod-name>

Step 3: Are there Kubernetes events?

kubectl describe pod <pod-name>

Step 4: Does the Service exist?

kubectl get svc

Step 5: Does the Service have endpoints?

kubectl get endpoints <service-name>

Step 6: Can another pod reach the Service?

Use a test container and:

curl http://<service-name>:<port>

Step 7: Does DNS work?

For example:

nslookup <service-name>

Step 8: Does external ingress work?

Test the externally exposed endpoint.

Step 9: Can the application reach external dependencies?

Test the required destination from inside the workload.

This approach prevents you from assuming that every connectivity problem is an ingress problem.

14. Container Insights for AKS

Azure Monitor Container insights provides monitoring capabilities for AKS.

It can provide visibility into:

• Container logs
• Kubernetes events
• Pod metrics
• Cluster information
• Resource utilization

The Live Data capability can provide direct access to AKS container logs, events, and pod metrics for real-time troubleshooting.

This can be particularly useful when you want Azure-based monitoring rather than relying exclusively on command-line Kubernetes tools.

Important distinction

kubectl logs is a Kubernetes-native method for retrieving container logs.

Container insights provides an Azure monitoring experience that can aggregate and visualize Kubernetes telemetry.

15. Azure Container Apps Monitoring

Azure Container Apps abstracts much of the underlying Kubernetes infrastructure.

Unlike AKS, you generally do not troubleshoot Container Apps by directly managing Kubernetes nodes and pods.

Instead, use Container Apps’ platform-level monitoring capabilities.

Important sources include:

• Container console logs
• System logs
• HTTP logs
• Log streams
• Azure Monitor
• Application Insights
• Metrics
• Diagnose and solve problems

16. Container App Console Logs

Container console logs originate from the application’s:

• stdout
• stderr

These are useful for diagnosing application-level problems.

For example:

Database connection failed

or:

Authentication failed

or:

Unhandled exception

These messages can help identify problems inside the application.

Azure Container Apps allows console logs to be viewed through the Azure portal and CLI.

17. Container Apps System Logs

System logs are generated by the Container Apps service rather than directly by the application.

They can help identify platform-level problems such as:

• Revision provisioning failures
• Container startup issues
• Configuration problems
• Volume mounting failures
• Dapr component issues
• Application configuration changes
• Other service-level events

This creates an important exam distinction:

18. Viewing Container Apps Log Streams

In the Azure portal, navigate to the Container App and select:

Monitoring → Log stream

You can select between:

• Console
• System

The console stream displays application/container output, while the system stream provides platform-level information.

You can also use the Azure CLI.

For example:

az containerapp logs show \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --type console

For system logs:

az containerapp logs show \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --type system

You can use --tail to limit the number of messages and --follow to continuously stream logs.

19. Container Apps Revisions and Replicas

Container Apps uses revisions and replicas.

This matters when troubleshooting because the application may have:

• Multiple revisions
• Multiple replicas
• Multiple containers

A log problem might exist only in one revision or replica.

Therefore, when investigating Container Apps logs, determine:

1. Which revision is receiving traffic?
2. Which replica is experiencing the problem?
3. Which container is producing the error?
4. Is the problem isolated or occurring across all replicas?

This is particularly important during deployments.

For example:

Revision A → healthy
Revision B → failing

If traffic has been shifted to Revision B, users may experience failures even though Revision A remains healthy.

20. Container Apps and Scaling to Zero

Container Apps can scale an application down to zero replicas depending on its scaling configuration.

This creates a potential troubleshooting trap.

If an application is scaled to zero, there may be no active replica from which to stream console logs.

If the log stream indicates that the revision is scaled to zero, you may need to temporarily configure a minimum replica count greater than zero to investigate the running application.

Exam Tip

If a Container App has no active replicas:

Don’t assume the application has crashed.

It may simply have scaled to zero.

21. Container Apps HTTP Logs

Container Apps can also provide HTTP-related telemetry through its ingress layer when diagnostic settings are configured.

These logs can help investigate:

• HTTP status codes
• Request behavior
• Client requests
• Ingress problems
• Application availability

This is useful when the container itself appears healthy but clients are receiving errors.

For example:

Client → Container Apps ingress → Container

If the container logs show no corresponding request, investigate the ingress/routing layer.

22. Diagnose and Solve Problems in Container Apps

Azure Container Apps provides a Diagnose and solve problems experience for investigating application health, configuration, and performance.

This can be useful when problems are not immediately obvious from application logs.

For example, Container Apps diagnostics can help investigate container exit events and provide information about possible causes and resolutions.

23. AKS vs. Container Apps Troubleshooting

Understanding the difference between AKS and Container Apps is important for AI-200.

Key Exam Principle

If a question emphasizes:

Pods, nodes, Services, Deployments, Kubernetes events, kubectl

think:

AKS

If it emphasizes:

Revisions, replicas, Container Apps log streams, system logs, console logs, ingress

think:

Azure Container Apps

24. Troubleshooting Common AKS Problems

Problem: Pod is Pending

Check:

kubectl describe pod <pod-name>

Look for events such as:

FailedScheduling

Potential causes include:

• Insufficient CPU
• Insufficient memory
• Node constraints
• Affinity rules
• Taints and tolerations
• Resource quotas

Problem: ImagePullBackOff

Check:

kubectl describe pod <pod-name>

Potential causes include:

• Incorrect image name
• Incorrect image tag
• Private registry authentication
• Network connectivity to the registry
• Image does not exist

Problem: CrashLoopBackOff

Check:

kubectl logs <pod-name>

Then:

kubectl logs <pod-name> --previous

And:

kubectl describe pod <pod-name>

Potential causes include:

• Application crash
• Invalid configuration
• Missing secret
• Failed dependency connection
• Failed liveness probe
• Incorrect startup behavior

Problem: Pod is Running but Requests Fail

Investigate:

1. Application logs
2. Pod readiness
3. Service configuration
4. Service endpoints
5. DNS
6. Network policies
7. Ingress/load balancer
8. External networking

A Running status does not guarantee that an application is reachable.

25. Troubleshooting Common Container Apps Problems

Problem: Container exits

Check:

• Console logs
• System logs
• Container exit events
• Revision status
• Application startup configuration

A zero exit code can indicate normal termination, while a nonzero exit code generally indicates failure. Container Apps provides diagnostic information about container exit events.

Problem: Application is unavailable

Check:

1. Active revision
2. Replica count
3. Ingress configuration
4. Console logs
5. System logs
6. HTTP logs
7. Health probes
8. Application dependencies

Problem: New deployment fails

Check:

• Revision provisioning
• Container image
• Environment variables
• Secrets
• Managed identity
• Registry access
• Container startup
• Application logs

A new revision can fail while a previous revision continues to operate.

26. Troubleshooting End-to-End Connectivity

End-to-end connectivity problems require a broader perspective.

Consider an AI application with this architecture:

User
  |
  v
Azure Front Door / Application Gateway
  |
  v
Container App or AKS Ingress
  |
  v
Application
  |
  +------> Azure OpenAI
  |
  +------> Azure Cosmos DB
  |
  +------> Azure Service Bus
  |
  +------> Azure Storage

A failure could occur anywhere along this path.

The correct troubleshooting approach is to identify the first point at which communication fails.

27. Test from the Same Network Context

A common troubleshooting mistake is testing connectivity from your laptop when the actual application runs inside Azure.

For example:

Laptop → Azure service

may work while:

Container → Azure service

fails.

The application should therefore be tested from the same network context in which it runs.

For AKS, this may mean executing commands from a diagnostic pod.

For Container Apps, troubleshooting may involve application logs, platform diagnostics, ingress configuration, and network configuration.

28. DNS Troubleshooting

DNS problems can make a healthy application appear unavailable.

Suppose an application attempts:

https://my-database.example.com

but cannot resolve the hostname.

The application may produce errors such as:

Name or service not known

or:

DNS resolution failed

In AKS, test DNS from inside the cluster:

nslookup <hostname>

or:

nslookup <service-name>

If DNS resolution fails, investigate DNS configuration before investigating the application itself.

29. Port and Protocol Troubleshooting

A common problem is confusing:

• Container port
• Service port
• Target port
• External port

For example:

Client
  |
  | TCP 443
  v
Ingress
  |
  | TCP 8080
  v
Service
  |
  | TCP 8080
  v
Pod

The application must actually be listening on the expected port.

A connectivity test such as:

nc -z -v <host> <port>

can help determine whether a TCP port is reachable.

30. Application Connectivity vs. Infrastructure Connectivity

Another important distinction is:

Can the network connection be established?

versus:

Does the application successfully process the request?

For example:

TCP connection succeeds
        |
        v
HTTP 500

The network is functioning, but the application has an error.

Conversely:

Connection timeout

may indicate a networking, routing, firewall, DNS, or service availability problem.

The HTTP response code and application logs should therefore be considered together.

31. A Practical AKS Troubleshooting Playbook

When an AKS application is unavailable, use this sequence.

Step 1 — Check pods

kubectl get pods -A

Step 2 — Inspect unhealthy pods

kubectl describe pod <pod-name>

Step 3 — Read logs

kubectl logs <pod-name>

Step 4 — Check previous container logs

kubectl logs <pod-name> --previous

Step 5 — Check events

kubectl get events

Step 6 — Check Services

kubectl get svc

Step 7 — Check endpoints

kubectl get endpoints <service-name>

Step 8 — Test DNS

nslookup <service-name>

Step 9 — Test connectivity

curl http://<service-name>:<port>

Step 10 — Investigate ingress and external networking

Only after the internal application path is confirmed should you move farther outward.

32. A Practical Container Apps Troubleshooting Playbook

For Azure Container Apps:

Step 1 — Check revision status

Determine whether the expected revision is active and healthy.

Step 2 — Check replica state

Determine whether the application has active replicas or has scaled to zero.

Step 3 — Inspect console logs

Look for application-level errors.

Step 4 — Inspect system logs

Look for platform and revision-level problems.

Step 5 — Inspect HTTP/ingress telemetry

Determine whether requests are reaching the application.

Step 6 — Check configuration

Review:

• Environment variables
• Secrets
• Managed identity
• Registry configuration
• Ingress
• Health probes

Step 7 — Check external dependencies

Determine whether the application can communicate with required Azure services.

Step 8 — Use Azure diagnostics

Use the Container Apps diagnostic capabilities when the source of the problem remains unclear.

33. Common Troubleshooting Mistakes

Mistake 1: Assuming Running Means Healthy

A pod can be Running while the application inside it is broken.

Use readiness status, logs, and probes.

Mistake 2: Looking Only at Application Logs

Infrastructure events may reveal the actual problem.

For example:

ImagePullBackOff

is unlikely to be explained by an application log because the application may never have started.

Mistake 3: Looking Only at Events

Events can tell you that something happened, but application logs may explain why the application itself failed.

Use both.

Mistake 4: Troubleshooting Ingress First

If the pod isn’t running, spending time troubleshooting ingress is premature.

Work from the application outward.

Mistake 5: Ignoring Previous Container Logs

A restarted container may have lost the most useful evidence.

Use:

kubectl logs --previous

Mistake 6: Assuming a Container App with No Logs Is Broken

The application might be scaled to zero.

Check its replica/scaling state.

Mistake 7: Testing from the Wrong Location

A connection that succeeds from your development machine does not prove that it will succeed from the Azure-hosted application.

Test from the application’s network context whenever possible.

34. Exam-Focused Command Reference

35. Key Concepts to Remember for AI-200

The following distinctions are particularly important for exam preparation.

AKS

kubectl get

Use it to see the current state of Kubernetes resources.

kubectl describe

Use it to investigate resource configuration, status, conditions, and events.

kubectl logs

Use it to inspect application/container output.

kubectl logs --previous

Use it to inspect logs from a previous container instance.

kubectl get events

Use it to investigate Kubernetes lifecycle and scheduling events.

Services and endpoints

Use them to determine whether traffic can be routed from a Kubernetes Service to the intended pods.

Container insights

Use Azure Monitor capabilities for broader monitoring, logs, events, and metrics.

Azure Container Apps

Console logs

Application/container output.

System logs

Container Apps platform/service events.

HTTP logs

Ingress-level HTTP activity when configured.

Log stream

Near-real-time access to console and system logs.

Revisions

Different deployed versions of an application.

Replicas

Running instances of a revision.

Diagnose and solve problems

Azure’s diagnostic capabilities for investigating application health and platform problems.

36. Final Exam Strategy

When presented with a troubleshooting scenario, identify the symptom first.

If the question mentions:

CrashLoopBackOff

Think:

• kubectl logs
• kubectl logs --previous
• kubectl describe pod
• Health probes

ImagePullBackOff

Think:

• Image name/tag
• Container registry
• Authentication
• kubectl describe pod

FailedScheduling

Think:

• Node resources
• Scheduling constraints
• Taints/tolerations
• kubectl describe pod

Pod is Running but service is unreachable

Think:

• Service
• Selector
• Endpoints
• DNS
• Ports
• Network policies
• Ingress

Container Apps application error

Think:

• Console logs

Container Apps platform/revision problem

Think:

• System logs
• Revision status

Container App has no active replica

Think:

• Scaling to zero

Requests reach the application but return HTTP errors

Think:

• Application logs
• HTTP logs
• Dependency failures

Application cannot reach an Azure service

Think:

• DNS
• Network routing
• Firewall/network restrictions
• Identity/authentication
• Service availability
• Test from the application’s network context

The most important principle is:

Don’t troubleshoot the entire system at once. Start at the failing workload and move outward until you find the first broken connection or component.

Practice Exam Questions

Question 1

An application running on AKS repeatedly enters the CrashLoopBackOff state. The development team wants to determine what happened immediately before the most recent container restart.

Which command should you use?

A. kubectl get svc <pod-name>

B. kubectl logs <pod-name> --previous

C. kubectl get events --all-namespaces

D. kubectl top nodes

Answer: B

Explanation:
kubectl logs --previous retrieves logs from the previous instance of a container. This is particularly useful when a container has crashed and restarted. kubectl get events can provide additional context, but it does not provide the application’s actual log output from the previous container instance.

Question 2

An AKS pod remains in the Pending state. You need to determine why Kubernetes has not scheduled the pod onto a node.

Which action should you take first?

A. Run kubectl logs on the pod.

B. Restart the deployment.

C. Run kubectl describe pod and inspect the Events section.

D. Check the application’s HTTP logs.

Answer: C

Explanation:
kubectl describe pod provides detailed information about the pod and its associated events. Scheduling failures such as insufficient resources, taints, affinity constraints, or other scheduling problems are commonly reported there. A pod that has not started generally will not have useful application logs.

Question 3

An AKS application is running successfully in its pod. However, requests sent through a Kubernetes Service do not reach the application.

Which investigation is most appropriate next?

A. Check whether the Service has endpoints corresponding to the application pods.

B. Restart the AKS cluster.

C. Examine only the application’s CPU utilization.

D. Delete and recreate the container image.

Answer: A

Explanation:
A healthy pod does not guarantee that a Service is routing traffic to it. Checking the Service and its endpoints helps determine whether the Service selector matches the intended pods and whether usable endpoints have been registered.

Question 4

An Azure Container Apps application is returning errors. The developer wants to see messages written by the application’s container to stdout and stderr.

Which log source should be inspected?

A. Container Apps system logs

B. Azure Activity Log

C. Kubernetes events

D. Container Apps console logs

Answer: D

Explanation:
Container Apps console logs contain output from the application’s containers, including stdout and stderr. System logs instead contain information generated by the Container Apps service.

Question 5

An Azure Container Apps application was working yesterday but now appears to have no running instances. No application errors are visible in the console log stream.

What should you investigate first?

A. Whether the container image has been deleted.

B. Whether the application has scaled to zero replicas.

C. Whether Kubernetes nodes are running.

D. Whether the AKS API server is reachable.

Answer: B

Explanation:
Container Apps can scale applications to zero replicas depending on the configured scaling rules. When no replicas are running, there may be no active container instance producing console logs. AKS node and API-server troubleshooting is not appropriate because Container Apps abstracts the underlying Kubernetes infrastructure.

Question 6

An AKS application is accessible from one pod but cannot resolve the DNS name of another Kubernetes Service.

Which troubleshooting technique is most appropriate?

A. Increase the pod’s CPU limit.

B. Restart every node in the cluster.

C. Run a DNS lookup such as nslookup from the application’s network context.

D. Rebuild the container image.

Answer: C

Explanation:
If the problem appears to be DNS resolution, testing DNS from inside the cluster helps determine whether the workload can resolve the target name. Testing from the same network context as the application is important because DNS behavior can differ between environments.

Question 7

A new revision of an Azure Container Apps application fails during deployment, while the previous revision continues to operate correctly.

Which information is most useful for determining whether the new revision encountered a platform-level provisioning problem?

A. The system logs for the Container App

B. The developer’s local application logs

C. The user’s browser cache

D. The CPU utilization of an unrelated Azure VM

Answer: A

Explanation:
Container Apps system logs contain platform-level information, including revision provisioning and service-level events. They are therefore appropriate when investigating deployment or revision provisioning failures.

Question 8

An AKS application is running, but clients receive connection timeouts. The development team wants to troubleshoot the problem using an inside-out approach.

Which sequence is most appropriate?

A. Check the external client, then immediately restart the cluster.

B. Check the Azure subscription, then rebuild the application.

C. Check the ingress first and ignore the pods.

D. Check the pod/application, then Service and endpoints, then networking and external access.

Answer: D

Explanation:
An inside-out approach begins with the workload itself and progressively moves outward. First verify that the pod and application are healthy, then verify Service routing and endpoints, and finally investigate ingress and external networking. This approach helps identify the first layer where connectivity fails.

Question 9

An AKS application container is repeatedly restarted. The application logs show no obvious error, but kubectl describe pod reports repeated liveness probe failures.

What is the most likely area to investigate?

A. The Azure subscription’s billing configuration.

B. The container’s liveness probe configuration and application startup/health behavior.

C. The user’s browser DNS cache.

D. The container registry’s image retention policy.

Answer: B

Explanation:
Repeated liveness probe failures can cause Kubernetes to restart a container. The probe’s path, port, timing, timeout, and failure thresholds should be evaluated against the application’s actual startup and health behavior.

Question 10

An AI application running in AKS can connect to an external Azure service from a developer workstation but receives connection timeouts when running inside the cluster.

Which approach provides the most useful next diagnostic step?

A. Assume the external service is unavailable.

B. Increase the application’s memory allocation.

C. Test DNS and network connectivity to the destination from inside the AKS network context.

D. Delete the application deployment and recreate it.

Answer: C

Explanation:
Successful connectivity from a developer workstation does not prove that connectivity from AKS is working. Testing DNS resolution and network connectivity from inside the cluster helps isolate problems involving routing, firewall rules, network policies, private endpoints, DNS, or other network-specific configuration.

Summary

For AI-200, monitoring and troubleshooting containerized applications is fundamentally about understanding where the failure occurs.

For AKS, become comfortable with:

• kubectl get
• kubectl describe
• kubectl logs
• kubectl logs --previous
• kubectl get events
• Services
• Endpoints
• DNS testing
• Connectivity testing
• Health probes
• Azure Monitor and Container insights

For Azure Container Apps, understand:

• Console logs
• System logs
• HTTP logs
• Log streams
• Revisions
• Replicas
• Scaling to zero
• Ingress
• Container exit events
• Azure diagnostics

Most importantly, develop an inside-out troubleshooting methodology:

Container → application → pod/replica → Service/ingress → network → external dependency

When you can identify the first layer where communication or execution breaks, you can usually identify the correct troubleshooting tool and the most appropriate remediation.

Go to the AI-200 Exam Prep Hub main page