Istio Certified Associate: Troubleshooting

What this domain tests

Troubleshooting tests whether you can localize a failure across the control plane, sidecar, gateway, and application. You need istioctl analyze, proxy-status, proxy-config, logs, and a clear model of Envoy xDS sync and endpoint health.

Core rules

• istioctl analyze finds static configuration problems such as missing gateways, conflicting policies, and invalid hosts.
• istioctl proxy-status shows whether each proxy is SYNCED, STALE, or NOT SENT. STALE means the control plane has newer config that the proxy has not received.
• istioctl proxy-config cluster|endpoint|listener|route <pod> inspects Envoy's actual view. Endpoint output reveals whether upstreams are healthy.
• 503 UF means no healthy upstream; 503 NR means no route; 404 at the gateway often means no matching VirtualService or listener.

Worked example

frontend gets 503 UF calling backend. proxy-status shows SYNCED, so config delivery is fine. proxy-config endpoint frontend-xxxx --cluster outbound|8080||backend.default.svc.cluster.local shows no healthy endpoints. The backend pods are Running but fail readiness, so Envoy has no upstream. Reasoning: UF is an upstream health problem, not a route problem. Fix readiness or the Service selector, then recheck endpoints.

Traps

• Reading only application logs and ignoring Envoy config; the sidecar may be rejecting traffic before the app sees it.
• Assuming STALE means the control plane is down; it often means a proxy is not receiving xDS.
• Forgetting that istioctl analyze cannot see pod readiness or runtime endpoint health.
• Debugging a gateway 404 without checking VirtualService host binding and gateway selection.
• Restarting istiod before checking proxy-config; the fault is often local endpoint or policy configuration.