Study guide
3.2 Monitor & Troubleshoot AKS and Container Apps
Exam AI-200: Developing AI Cloud Solutions on Azure Exam
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Audience Profile & Study Path
2 Chapter 1: Container Registry & App Service Hosting
1.1 ACR: Build, Store, Version & Manage Images 1.2 ACR Tasks: Build & Run Images 1.3 Deploy Containers to Azure App Service
3 Chapter 2: Azure Container Apps & KEDA Scaling
2.1 Azure Container Apps: Environments, Config & Revisions 2.2 KEDA Event-Driven Scaling in Container Apps
4 Chapter 3: AKS Manifests & Container Troubleshooting
3.1 Deploy & Manage Apps on AKS with Manifests 3.2 Monitor & Troubleshoot AKS and Container Apps
5 Chapter 4: Cosmos DB for NoSQL Fundamentals
4.1 Cosmos DB for NoSQL: SDK Connect & Queries 4.2 Optimize RUs: Indexing Policies & Consistency Levels
6 Chapter 5: Cosmos DB Vectors & Change Feed
5.1 Embeddings & Vector Similarity Search in Cosmos DB 5.2 Change Feed Processor for New/Updated Items
7 Chapter 6: Azure PostgreSQL Foundations for AI
6.1 Azure Database for PostgreSQL: Connect & Query with SDKs 6.2 Schema Design, Data Types & Indexing Strategies 6.3 pgvector Indexing: Latency & Compute Overhead
8 Chapter 7: PostgreSQL Vector Workloads & RAG
7.1 Configure Compute, Memory & Storage for Vector Workloads 7.2 Vector Search, Semantic Retrieval & RAG with Metadata Filters 7.3 Connection Optimization for Throughput & Latency
9 Chapter 8: Azure Managed Redis for AI Solutions
8.1 Azure Managed Redis: Caching, Expiration & Invalidation 8.2 Redis Vector Indexing for Similarity Search
10 Chapter 9: Service Bus & Event Grid for AI Pipelines
9.1 Service Bus Queues & Message Processing 9.2 Topics, Subscriptions & Dead-Letter Queues 9.3 Event Grid: Custom Events & Filters 9.4 Event Grid Retries & Event-Driven Workflows
11 Chapter 10: Azure Functions for Serverless AI Back Ends
10.1 Azure Functions: Triggers & Bindings 10.2 Build Serverless APIs with Functions 10.3 Configure & Deploy Function Apps
12 Chapter 11: Key Vault & App Configuration
11.1 Azure Key Vault: Secret Storage & Retrieval 11.2 Key Vault Secret Rotation Patterns 11.3 Azure App Configuration for App Settings
13 Chapter 12: OpenTelemetry & KQL Observability
12.1 Distributed Tracing with OpenTelemetry SDKs 12.2 Correlating Traces into Azure Monitoring 12.3 Write KQL Queries to Analyze Logs 12.4 KQL for Metrics & Troubleshooting Scenarios
3.2 Monitor & Troubleshoot AKS and Container Apps
Key Takeaways Explain This Topic AI
Troubleshoot AKS with kubectl logs, kubectl describe, and kubectl get events to correlate container output with scheduling and probe failures
Azure Container Apps expose log streams via Log Analytics, console streaming, and system/console logs—different from kubectl on AKS
AKS vs ACA: AKS is full Kubernetes control plane troubleshooting; Container Apps abstract nodes and use revisions, replicas, and environment diagnostics
Connectivity failures often trace to DNS names, Ingress/Application Gateway routing, NSGs, or network policies—not only application bugs
End-to-end checks should verify Pod readiness, Service Endpoints, Ingress address, and path from client through Azure networking to the container
Last updated: July 2026
Monitor & Troubleshoot AKS and Container Apps
Quick Answer: On AKS, start with kubectl get / describe , kubectl logs , and Events to see why Pods crash or stay unready. On Azure Container Apps (ACA), use log streams and Log Analytics tied to the Container Apps environment. Always finish with connectivity checks—DNS, Ingress, and NSG/network paths—because many "app down" incidents are routing or firewall problems.
AI-200 expects you to diagnose container platforms, not only write manifests. You must know where logs live , how events explain controller decisions, and how to prove end-to-end connectivity on both AKS and Azure Container Apps.
AKS vs Azure Container Apps: Troubleshooting Posture
- Concern AKS Azure Container Apps
- Abstraction Full Kubernetes API (Pods, Deployments, Nodes) Serverless containers; revisions & replicas
- Primary CLI kubectl , az aks az containerapp , portal log stream
- Logs kubectl logs , Container Insights optional Console/system logs → Log Analytics
Networking Services, Ingress, CNI, NSG, NetworkPolicy Ingress (external/internal), VNet integration, env-level networking
Scale signals HPA/metrics on Pods Scale rules (HTTP, KEDA-style, CPU) on app
Choose the tool that matches the platform. Running kubectl against Container Apps will not work—the control plane is not exposed as a customer-managed Kubernetes API in the same way.
AKS: Inspect Workloads Systematically
A reliable order of operations:
- Status — kubectl get pods,deploy,svc,ingress -n <ns> -o wide
- Describe — kubectl describe pod <name> -n <ns> (Events at the bottom)
- Logs — kubectl logs <pod> -n <ns> / -c <container> / --previous
- Cluster events — kubectl get events -n <ns> --sort-by=.lastTimestamp
- Connectivity — Endpoints, DNS, Ingress IP, NSG/firewall
- kubectl describe: Conditions and Events
describe surfaces:
- Pod phase and container state ( Waiting , CrashLoopBackOff , Running )
- Probe failures ("Liveness probe failed", "Readiness probe failed")
- Image pull errors and mount failures
- Scheduling messages (Insufficient CPU/memory, taints/tolerations)
Events are time-ordered clues from the kubelet and controllers. A Deployment showing ProgressDeadlineExceeded often pairs with Pod Events about failed pulls or crash loops.
- kubectl logs: Application Truth kubectl logs deploy/inference-api -n ml-apps --tail=200
- kubectl logs pod/inference-api-7f9c8 -n ml-apps -c api
- kubectl logs pod/inference-api-7f9c8 -n ml-apps --previous
--previous reads the last terminated container instance—essential for CrashLoopBackOff where the current container just restarted empty. Multi-container Pods require -c because logs are per container.
If logs are empty but the Pod is crashing, look at describe/Events for OOMKilled, failed mounts, or missing Secrets—those fail before useful stdout exists.
Common AKS Symptom → First Check
- Symptom First inspection
- ImagePullBackOff Image name/tag, ACR attachment, pull secret
- CrashLoopBackOff logs --previous , exit code, missing env
- Pending Node resources, PVC binding, taints
- Ready 0/1 forever readinessProbe path/port, app listen address
- Service times out Endpoints empty? selector/labels; NetworkPolicy
- Ingress 502/504 Backend Service/Endpoints; probe; controller health
- Azure Container Apps: Logs and Revisions
Container Apps package each deployment as a revision . Troubleshooting focuses on:
- Replica status — activating, running, failed
- Console log stream — near-real-time stdout/stderr in portal or CLI
- System logs — platform messages (scaling, ingress, Dapr if used)
- Log Analytics — query historical logs with Kusto when streaming is not enough
- Typical CLI patterns: az containerapp logs show -n myapp -g myrg --follow
- az containerapp revision list -n myapp -g myrg -o table
- az containerapp show -n myapp -g myrg --query properties.configuration.ingress
When a new revision fails activation, compare revision traffic weights, environment variables, secrets, and ingress external vs internal settings. Scale-to-zero can look like "the app is down" when it is simply cold-starting—check replica counts and scale rules before blaming code.
Container Apps environments share Log Analytics configuration; if queries return nothing, verify diagnostic settings and that you are querying the correct workspace table for Container App console/system logs.
Connectivity: DNS, Ingress, and Network Controls
Many container incidents are path problems. Work outside-in and inside-out.
DNS
- Scope What to verify
- In-cluster (AKS) service.namespace.svc.cluster.local resolution from a debug Pod
- Public App hostname → Ingress/App Gateway/Container Apps FQDN via public DNS
- Private Private DNS zones for internal Ingress or VNet-integrated ACA
Wrong namespace in the DNS name, stale CoreDNS, or missing private zone links produce intermittent or hard failures that never appear in application logs.
Ingress and Application Gateways
For AKS Ingress: confirm the Ingress has an ADDRESS, the controller Pods are healthy, TLS secrets exist, and path/backend Service ports match. For AGIC or Application Gateway for Containers, also check Azure-side backend pool health probes—Azure may mark backends unhealthy even when kubectl logs looks fine.
For Container Apps: confirm ingress is enabled, traffic mode (external/internal), and that the client uses the correct FQDN and HTTPS settings. Internal ingress requires network path into the environment's VNet.
NSG, Firewall, and Network Policy
- Control Typical break
- NSG on AKS subnet / ACA delegated subnet Blocks Azure LB health probes or client ports
- Azure Firewall / NVA Egress blocked for image pulls or dependency APIs
- Kubernetes NetworkPolicy Pod cannot reach Service or egress
- Private cluster API Admin kubectl fails without VPN/private endpoint path
When Pods are Running and logs look healthy but external users time out, prioritize NSG effective security rules, load balancer health probe status, and whether the Ingress public IP is reachable. When only some Pod-to-Pod calls fail, inspect NetworkPolicies and CoreDNS.
End-to-End Connectivity Checklist
Use this exam-friendly sequence:
- Container healthy? Logs without crash loops; readiness Passing
- Service layer? AKS Endpoints non-empty / ACA ingress shows running replicas
- Edge routing? Ingress/App Gateway/Container Apps URL returns expected status from inside Azure
- Client path? Public DNS and TLS; NSG allows client → frontend; no corporate proxy MITM surprises
- Dependencies? App can resolve and reach databases/APIs (egress NSG, private endpoints, connection strings)
- Observability Add-ons
Production AKS often enables Container Insights (Azure Monitor) for node/Pod metrics and log aggregation. Container Apps lean on Log Analytics and metrics in Azure Monitor. Knowing which store holds historical data matters when the live log stream has already rotated.
Putting It Together
Treat AKS troubleshooting as Kubernetes-native: describe → events → logs → Endpoints → network. Treat Container Apps as managed revision/replica diagnostics plus environment logs. In both worlds, prove connectivity separately from application exceptions. That split— platform signal versus app signal versus network path —is what AI-200 scenarios test when a containerized solution "does not work" on Azure.