Istio Certified Associate (ICA) Study Guide

Environment	Options	Best For
☁️ Cloud Playgrounds	KodeKloud, Killercoda, Play with Kubernetes	Quick practice, no setup required
💻 Local Clusters	Minikube, kind, k3d, Docker Desktop	Offline practice, full control
🏢 Managed K8s	GKE, EKS, AKS with Istio addon	Production-like experience

Exam Detail	Information
Duration	2 hours
Passing Score	75%
Cost	$250 USD (includes one free retake)
Format	Performance-based + Multiple choice
Certification Validity	3 years

Domain 1 • 20% Weight

Installation, Upgrade & Configuration

This domain tests your ability to deploy Istio using different methods, customize installations to match requirements, and safely upgrade production meshes without downtime.

Installing Istio with istioctl

Think of istioctl as your primary interface to the Istio control plane. It's more than just an installer—it's a comprehensive diagnostic and management tool that understands Istio's architecture deeply. When you install Istio using istioctl, you're leveraging the IstioOperator API, which provides a declarative way to specify exactly what you want installed and how it should be configured.

The beauty of istioctl's approach is in its installation profiles. Rather than starting from scratch every time, Istio provides pre-configured profiles optimized for different scenarios. The default profile gives you a production-ready starting point with just the control plane (istiod) and an ingress gateway. The demo profile enables nearly everything—it's designed for learning and evaluation.

Getting Started with Istio Installation

If your environment has Istio pre-installed, verify it. Otherwise, you can install Istio using the commands below.

bash

# Verify istioctl is available
istioctl version

# List all available installation profiles
istioctl profile list

# View the complete configuration for a profile
istioctl profile dump demo

# Compare two profiles to understand differences
istioctl profile diff default demo

# Check current installation status
kubectl get pods -n istio-system

# Run pre-installation checks
istioctl x precheck

Profile	Use Case	Components Installed
default	Production starting point	istiod, Ingress Gateway
demo	Learning and evaluation	All components, higher trace sampling
minimal	Control plane only	istiod only (no gateways)
ambient	Sidecar-less mesh	istiod, CNI, ztunnel
empty	Base for custom profiles	Nothing (define everything yourself)

💡

Pro Tip

Always run istioctl x precheck before installing or upgrading. This command validates that your cluster meets Istio's requirements and identifies potential issues before they cause problems.

Customizing Your Istio Installation

While profiles provide excellent starting points, real-world deployments almost always require customization. The IstioOperator API gives you fine-grained control over every aspect of your installation. You can override individual settings using --set flags directly on the command line, or define a complete IstioOperator manifest for more complex configurations.

custom-install.yaml

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
  name: istio-control-plane
spec:
  profile: default
  
  # Mesh-wide configuration settings
  meshConfig:
    accessLogFile: /dev/stdout
    accessLogEncoding: JSON
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 100.0
      holdApplicationUntilProxyStarts: true
    outboundTrafficPolicy:
      mode: REGISTRY_ONLY
  
  # Component-level configuration
  components:
    pilot:
      enabled: true
      k8s:
        resources:
          requests:
            cpu: 500m
            memory: 2Gi
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true

📝

Understanding outboundTrafficPolicy

The REGISTRY_ONLY mode restricts outbound traffic to services defined in Istio's service registry. This is more secure but requires ServiceEntry resources for external services. ALLOW_ANY permits traffic to any destination.

Sidecar Mode vs. Ambient Mode

Istio's traditional architecture uses the sidecar pattern—an Envoy proxy container is injected into every application pod, intercepting all network traffic for that workload. This approach provides comprehensive L4/L7 traffic management but adds resource overhead to every pod in your mesh.

Ambient mode represents Istio's answer to this challenge. Instead of per-pod sidecars, ambient mode uses a shared ztunnel component running on each node that handles L4 security (mTLS) for all pods on that node. For workloads needing L7 features, you deploy waypoint proxies. This architecture can reduce proxy resource usage by up to 90%.

bash

# Enable SIDECAR injection for a namespace
kubectl label namespace default istio-injection=enabled

# Verify namespace labels
kubectl get namespace -L istio-injection

# Enable AMBIENT mode for a namespace (alternative)
kubectl label namespace default istio.io/dataplane-mode=ambient

# Check which mode is enabled
kubectl get namespaces -L istio-injection,istio.io/dataplane-mode

# Disable injection for specific pod (annotation)
# sidecar.istio.io/inject: "false"

Canary Upgrades

Upgrading a service mesh in production requires careful planning. Istio supports canary upgrades which run multiple control plane versions simultaneously, enabling gradual workload migration and safe rollback. Each control plane installation gets a unique revision label, and namespaces are labeled to indicate which revision they should use.

bash

# Step 1: Install new revision alongside existing
istioctl install --set revision=1-21-0

# Verify both control planes running
kubectl get pods -n istio-system -l app=istiod

# Step 2: Migrate namespaces to new revision
kubectl label namespace test-ns istio-injection- istio.io/rev=1-21-0

# Step 3: Restart workloads to get new sidecars
kubectl rollout restart deployment -n test-ns

# Step 4: Verify migration
istioctl proxy-status

# Step 5: After migrating ALL namespaces, remove old revision
istioctl uninstall --revision 1-20-1 -y

⚠️

Important Upgrade Consideration

After changing namespace labels or revision tags, existing pods still run with their old sidecar version. You must restart pods (using kubectl rollout restart) for them to receive the new sidecar version.

📋 Domain 1 Exam Checklist

Install Istio with istioctl using different profiles (default, demo, minimal)

Create and apply custom IstioOperator configurations

Enable sidecar injection for namespaces and verify injection

Understand sidecar vs ambient mode differences

Perform a canary upgrade using revisions

🔑 Key Concepts to Memorize

Concept	Details
Sidecar Injection Label	istio-injection=enabled
Ambient Mode Label	istio.io/dataplane-mode=ambient
Disable Injection (Pod)	sidecar.istio.io/inject: "false"
Revision Label	istio.io/rev=<revision>
Control Plane Namespace	istio-system
Control Plane Component	istiod (Pilot, Citadel, Galley combined)
Default Profile Components	istiod + Ingress Gateway
Demo Profile	All components + higher trace sampling

🎯

Exam Scenario: Installation Troubleshooting

If pods don't get sidecars after labeling namespace: (1) Check namespace label exists, (2) Verify istio-sidecar-injector webhook, (3) Restart pods - existing pods won't automatically get sidecars!

📚 Official Documentation References

Bookmark these pages for exam preparation and quick reference:

📖 Install with istioctlInstallation methods and profiles 📖 Sidecar InjectionAutomatic and manual injection 📖 Canary UpgradesRevision-based upgrades 📖 IstioOperator APIConfiguration reference 📖 MeshConfigMesh-wide configuration options 📖 Ambient ModeSidecar-less architecture

Domain 2 • 35% Weight

Traffic Management

This is the largest domain, and for good reason—traffic management is at the heart of what makes a service mesh valuable. You'll learn to control how requests flow through your mesh using Gateways, VirtualServices, and DestinationRules.

Setting Up the Practice Environment

Before diving into traffic management, let's deploy the Bookinfo sample application that we'll use throughout this section. This microservices application includes productpage, details, reviews (v1, v2, v3), and ratings services—perfect for practicing routing scenarios.

bash

# Ensure sidecar injection is enabled
kubectl label namespace default istio-injection=enabled --overwrite

# Deploy the Bookinfo application
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/bookinfo/platform/kube/bookinfo.yaml

# Wait for all pods to be ready
kubectl get pods -w

# Deploy the Gateway and VirtualService for external access
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/bookinfo/networking/bookinfo-gateway.yaml

# Deploy destination rules (defines subsets)
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/bookinfo/networking/destination-rule-all.yaml

# Verify the application
kubectl exec "$(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}')" \
  -c ratings -- curl -s productpage:9080/productpage | grep -o "<title>.*</title>"

Configuring Ingress with Gateway

The Gateway resource is your mesh's front door—it configures the load balancer that sits at the edge of your service mesh, accepting traffic from outside and directing it inward. Think of it as configuring the "what" of edge traffic: which ports to listen on, which protocols to accept, and which hostnames to serve.

bookinfo-gateway.yaml

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

Configuring Routing with VirtualService

The VirtualService is where the real routing magic happens. While a Gateway just opens the door, the VirtualService decides where each request should go based on its characteristics—URI paths, HTTP headers, query parameters, or percentage-based weights for canary deployments.

reviews-routing.yaml

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  # Route user "jason" to reviews v2 (black stars)
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  # Default: Everyone else goes to v1 (no stars)
  - route:
    - destination:
        host: reviews
        subset: v1

Defining Traffic Policies with DestinationRule

If VirtualService is about routing (which version to send traffic to), DestinationRule is about policy (how to communicate with that version). DestinationRules define traffic policies that apply after routing decisions are made—load balancing algorithms, connection pooling, outlier detection for circuit breaking, and TLS settings.

reviews-destination-rule.yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 100
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3

Traffic Shifting (Canary Deployments)

Traffic shifting enables safe, gradual rollouts of new service versions. Instead of switching all traffic at once, you can shift 1%, then 5%, then 20%, monitoring metrics at each stage. If problems emerge, simply adjust the weights back—no redeployment required.

traffic-shifting.yaml

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 80
    - destination:
        host: reviews
        subset: v3
      weight: 20

External Services with ServiceEntry

ServiceEntry adds external services to Istio's service registry, enabling traffic management and observability for external API calls. When outboundTrafficPolicy.mode: REGISTRY_ONLY is set, the mesh will block traffic to services not in the registry.

external-service.yaml

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: httpbin-ext
spec:
  hosts:
  - httpbin.org
  ports:
  - number: 443
    name: https
    protocol: TLS
  location: MESH_EXTERNAL
  resolution: DNS

Resilience: Timeouts, Retries, Circuit Breaking

Istio provides several resilience patterns—timeouts, retries, circuit breaking, and outlier detection—that protect your system from cascading failures without requiring application code changes.

resilience-config.yaml

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
    timeout: 10s
    retries:
      attempts: 3
      perTryTimeout: 3s
      retryOn: 5xx,reset,connect-failure

🎯

Exam Focus: Where to Configure What

VirtualService: Timeouts, retries, fault injection, routing rules
DestinationRule: Load balancing, connection pools, circuit breaking, TLS settings, subsets

Fault Injection for Testing

Fault injection lets you simulate failures in a controlled way. Inject delays to test timeout handling, or inject aborts (HTTP errors) to verify error handling. You can target specific users via headers or affect a percentage of all traffic.

fault-injection.yaml

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    fault:
      delay:
        percentage:
          value: 100
        fixedDelay: 7s
    route:
    - destination:
        host: ratings
  - route:
    - destination:
        host: ratings

📋 Domain 2 Exam Checklist

Create Gateway resources for ingress traffic

Configure VirtualService with URI, header, and weight-based routing

Define DestinationRule subsets and traffic policies

Implement traffic shifting for canary deployments

Create ServiceEntry for external services

Configure timeouts, retries, and circuit breaking

Inject faults (delays and aborts) for testing

🔑 Key Concepts to Memorize

Resource	Purpose	Key Fields
Gateway	Edge load balancer configuration	selector, servers (port, hosts, tls)
VirtualService	Routing rules (WHERE to send)	hosts, gateways, http (match, route, timeout, retries, fault)
DestinationRule	Traffic policies (HOW to communicate)	host, trafficPolicy, subsets
ServiceEntry	Add external services to registry	hosts, ports, location, resolution
Sidecar	Limit proxy scope	workloadSelector, egress

Load Balancer Mode	Description
ROUND_ROBIN	Default, cycles through endpoints
LEAST_REQUEST	Routes to endpoint with fewest active requests
RANDOM	Random selection
PASSTHROUGH	Direct connection to original destination

🎯

Exam Gotcha: VirtualService + DestinationRule

A VirtualService routing to a subset requires a DestinationRule that defines that subset. Without it, you'll get "no healthy upstream" errors. Always create the DestinationRule first!

⚠️

Common Exam Mistake: Traffic Weights

Traffic weights must add up to 100. If using two destinations with weights 80/20, both must be specified. Also remember: weights are specified in VirtualService, subsets are defined in DestinationRule.

📚 Official Documentation References

Bookmark these pages for exam preparation and quick reference:

📖 Gateway ReferenceEdge traffic configuration 📖 VirtualService ReferenceRouting rules and match conditions 📖 DestinationRule ReferenceSubsets and traffic policies 📖 ServiceEntry ReferenceExternal service registration 📖 Fault InjectionTesting with delays and aborts 📖 Circuit BreakingResilience patterns 📖 Timeouts & RetriesRequest resilience 📖 Traffic MirroringShadow traffic for testing

Domain 3 • 25% Weight

Securing Workloads

Security is foundational to Istio's value proposition. This domain covers authentication (proving identity with mTLS and JWT), authorization (controlling who can access what), and securing edge traffic with TLS.

Configuring mTLS with PeerAuthentication

Mutual TLS (mTLS) is one of Istio's most valuable security features. With mTLS, both the client and server present certificates to prove their identity. Istio manages the certificate lifecycle automatically—each workload gets a SPIFFE identity and short-lived X.509 certificate that's automatically rotated.

mTLS Mode	Behavior	Use Case
STRICT	Only accept mTLS connections	Production, security-critical workloads
PERMISSIVE	Accept both mTLS and plaintext	Migration, mixed environments
DISABLE	Don't use mTLS for this scope	Legacy services that can't use TLS

peer-authentication.yaml

# Mesh-wide STRICT mTLS
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

Authorization with AuthorizationPolicy

AuthorizationPolicy controls what services can do. It's Istio's access control mechanism, letting you define fine-grained rules about which services can access which endpoints. Evaluation order: CUSTOM → DENY → ALLOW → implicit deny.

authorization-policy.yaml

# Default deny-all for namespace
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  {}
---
# Allow specific access
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: reviews-viewer
  namespace: default
spec:
  selector:
    matchLabels:
      app: reviews
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - "cluster.local/ns/default/sa/bookinfo-productpage"
    to:
    - operation:
        methods:
        - "GET"

JWT Authentication

RequestAuthentication enables end-user authentication using JSON Web Tokens (JWTs). It validates tokens but doesn't require them—requests without tokens pass through. To require authentication, combine with an AuthorizationPolicy that checks for the presence of a request principal.

jwt-authentication.yaml

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: jwt-auth
spec:
  selector:
    matchLabels:
      app: httpbin
  jwtRules:
  - issuer: "https://accounts.google.com"
    jwksUri: "https://www.googleapis.com/oauth2/v3/certs"
---
# Require valid JWT
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
spec:
  selector:
    matchLabels:
      app: httpbin
  action: ALLOW
  rules:
  - from:
    - source:
        requestPrincipals:
        - "*"

Gateway TLS Configuration

The Gateway resource supports three TLS modes: SIMPLE (standard TLS termination), MUTUAL (client certificate required), and PASSTHROUGH (SNI-based routing without termination).

bash

# Create TLS secret for Gateway
kubectl create -n istio-system secret tls bookinfo-credential \
  --key=bookinfo.example.com.key \
  --cert=bookinfo.example.com.crt

secure-gateway.yaml

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: secure-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "bookinfo.example.com"
    tls:
      mode: SIMPLE
      credentialName: bookinfo-credential

📋 Domain 3 Exam Checklist

Configure mesh-wide, namespace, and workload-level PeerAuthentication

Understand mTLS modes: STRICT, PERMISSIVE, DISABLE

Create ALLOW and DENY AuthorizationPolicies

Configure RequestAuthentication for JWT validation

Configure Gateway TLS modes: SIMPLE, MUTUAL, PASSTHROUGH

🔑 Key Concepts to Memorize

Security Resource	Purpose	Scope Options
PeerAuthentication	mTLS settings (workload identity)	Mesh → Namespace → Workload
AuthorizationPolicy	Access control (who can access what)	Mesh → Namespace → Workload
RequestAuthentication	JWT validation (end-user identity)	Namespace → Workload

AuthorizationPolicy Action	Evaluation Order	Behavior
CUSTOM	1st	Delegate to external auth
DENY	2nd	Explicit deny (if matched)
ALLOW	3rd	Explicit allow (if matched)
Implicit deny	4th	Deny if no ALLOW matched (when ALLOW policies exist)

Gateway TLS Mode	Client Cert Required?	Use Case
SIMPLE	No	Standard HTTPS (server cert only)
MUTUAL	Yes	mTLS at gateway edge
PASSTHROUGH	N/A	SNI routing, TLS handled by backend
AUTO_PASSTHROUGH	N/A	SNI routing without VirtualService

🎯

Exam Critical: Principal Formats

Service Account: cluster.local/ns/{namespace}/sa/{service-account}
JWT Principal: {issuer}/{subject}
SPIFFE ID: spiffe://cluster.local/ns/{namespace}/sa/{service-account}

⚠️

Common Exam Mistake: Empty Spec

spec: {} in AuthorizationPolicy = deny all (zero-trust default)
rules: [{}] in AuthorizationPolicy = match all (use with DENY action)

📚 Official Documentation References

Bookmark these pages for exam preparation and quick reference:

📖 PeerAuthentication ReferencemTLS configuration 📖 AuthorizationPolicy ReferenceAccess control rules 📖 RequestAuthentication ReferenceJWT validation 📖 mTLS MigrationPERMISSIVE to STRICT 📖 Authorization TasksPolicy examples 📖 Secure GatewaysTLS at ingress

Domain 4 • 20% Weight

Troubleshooting

When things go wrong, you need systematic approaches to diagnose issues. This domain covers configuration validation, control plane diagnostics, and data plane debugging.

Configuration Analysis with istioctl analyze

istioctl analyze is your first line of defense against configuration issues. It validates your Istio resources against known problems and best practices, catching issues before they cause production problems.

bash

# Analyze all namespaces
istioctl analyze --all-namespaces

# Analyze specific namespace
istioctl analyze -n default

# Analyze local files without applying
istioctl analyze --use-kube=false my-config.yaml

# Suppress specific warnings
istioctl analyze --suppress "IST0102=Namespace default"

Proxy Synchronization Status

istioctl proxy-status shows whether each sidecar is synchronized with the control plane. All proxies should show "SYNCED" for each configuration type (CDS, LDS, EDS, RDS). A "STALE" status indicates problems.

bash

# Check synchronization status of all proxies
istioctl proxy-status

# Status meanings:
# SYNCED   - Proxy acknowledged latest config
# NOT SENT - Nothing to send (normal)
# STALE    - Config sent but not acknowledged (problem!)

Config Type	Full Name	What It Configures
CDS	Cluster Discovery	Upstream clusters (services)
LDS	Listener Discovery	Ports proxy listens on
EDS	Endpoint Discovery	Actual pod IPs
RDS	Route Discovery	VirtualService rules

Inspecting Proxy Configuration

istioctl proxy-config lets you inspect exactly what configuration a sidecar has received—clusters, listeners, routes, endpoints, and secrets. Essential for debugging "why isn't my traffic going where I expect?"

bash

# View upstream clusters
istioctl proxy-config clusters productpage-v1-xxx.default

# View listeners
istioctl proxy-config listeners productpage-v1-xxx.default

# View routes
istioctl proxy-config routes productpage-v1-xxx.default --name 9080

# View endpoints
istioctl proxy-config endpoints productpage-v1-xxx.default

# View TLS certificates
istioctl proxy-config secret productpage-v1-xxx.default

# Get full JSON output
istioctl proxy-config routes productpage-v1-xxx.default -o json

Control Plane Troubleshooting

When proxies show STALE status or configuration isn't being applied, the control plane (istiod) is often where you should look first.

bash

# Check istiod pod status
kubectl get pods -n istio-system -l app=istiod

# View istiod logs
kubectl logs -n istio-system -l app=istiod --tail=100

# Verify version alignment
istioctl version

# Describe a workload's Istio config
istioctl experimental describe pod productpage-v1-xxx.default

# Check sidecar injection status
istioctl experimental check-inject -n default deployment/productpage-v1

Common Issues Quick Reference

🔴

503 Errors After DestinationRule

Add trafficPolicy.tls.mode: ISTIO_MUTUAL to your DestinationRule when using subsets with mesh-wide mTLS.

🔴

NR (No Route) in Access Logs

The proxy can't find a route for the request. Check VirtualService configuration and ensure the destination service exists.

🔴

UO (Upstream Overflow) Flag

Circuit breaker triggered due to connection pool limits. Review DestinationRule connectionPool settings.

Observability Tools

bash

# Install observability addons
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/prometheus.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/grafana.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/jaeger.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/kiali.yaml

# Open dashboards
istioctl dashboard kiali
istioctl dashboard prometheus
istioctl dashboard grafana
istioctl dashboard jaeger

📋 Domain 4 Exam Checklist

Use istioctl analyze to detect configuration issues

Check proxy synchronization with istioctl proxy-status

Inspect proxy configuration (clusters, listeners, routes, endpoints)

Troubleshoot istiod logs and health

Interpret Envoy access log response flags (NR, UO, UF)

🔑 Key Concepts to Memorize

proxy-config Type	Shows	Use When
clusters	Upstream services (CDS)	Service not found, subset issues
listeners	Port listeners (LDS)	Port not accessible, traffic not intercepted
routes	Routing rules (RDS)	Wrong destination, VirtualService not applied
endpoints	Pod IPs (EDS)	No healthy upstream, load balancing issues
secret	Certificates	mTLS failures, certificate expiry

Response Flag	Meaning	Common Cause
NR	No Route	VirtualService not matching, missing ServiceEntry
UH	No Healthy Upstream	All endpoints failed health checks
UF	Upstream Connection Failure	Network issues, pod not running
UO	Upstream Overflow	Circuit breaker tripped
UC	Upstream Connection Termination	Connection reset by peer
UT	Upstream Request Timeout	Request exceeded timeout
DC	Downstream Connection Termination	Client disconnected
RBAC	RBAC Access Denied	AuthorizationPolicy blocked request

Istio Port	Purpose
15000	Envoy admin interface
15001	Envoy outbound traffic
15006	Envoy inbound traffic
15010	Istiod xDS (plaintext)
15012	Istiod xDS (mTLS)
15014	Istiod metrics
15017	Webhook injection
15020	Merged Prometheus telemetry
15021	Health checks
15090	Envoy Prometheus

🎯

Exam Troubleshooting Workflow

1. istioctl analyze - Check for config errors
2. istioctl proxy-status - Verify all proxies SYNCED
3. istioctl proxy-config - Inspect specific proxy config
4. Check access logs for response flags
5. kubectl logs -l app=istiod -n istio-system - Control plane logs

📚 Official Documentation References

Bookmark these pages for exam preparation and quick reference:

📖 istioctl analyzeConfiguration analysis 📖 Debugging Envoyproxy-config commands 📖 Access LoggingLog format and flags 📖 Common ProblemsTroubleshooting guides 📖 Network IssuesTraffic problems 📖 Injection ProblemsSidecar issues 📖 Analysis MessagesError code reference 📖 Envoy Access LogResponse flag details

⚡ Essential Commands Quick Reference

Command	Purpose
istioctl install --set profile=<name>	Install Istio with profile
istioctl analyze -n <ns>	Detect configuration issues
istioctl proxy-status	Check proxy sync status
istioctl proxy-config clusters <pod> -n <ns>	View upstream clusters (CDS)
istioctl proxy-config routes <pod> -n <ns>	View routing config (RDS)
istioctl proxy-config listeners <pod> -n <ns>	View port listeners (LDS)
istioctl proxy-config endpoints <pod> -n <ns>	View endpoints (EDS)
istioctl proxy-config secret <pod> -n <ns>	View certificates
istioctl x describe pod <pod> -n <ns>	Describe pod config
istioctl x precheck	Pre-upgrade check
istioctl dashboard <tool>	Open dashboards (kiali, grafana, jaeger)
istioctl kube-inject -f <file>	Manual sidecar injection
kubectl label ns <ns> istio-injection=enabled	Enable auto sidecar injection

📝 API Resources Quick Reference

Resource	API Group	Short Name
Gateway	networking.istio.io/v1	gw
VirtualService	networking.istio.io/v1	vs
DestinationRule	networking.istio.io/v1	dr
ServiceEntry	networking.istio.io/v1	se
Sidecar	networking.istio.io/v1	-
PeerAuthentication	security.istio.io/v1	pa
AuthorizationPolicy	security.istio.io/v1	ap
RequestAuthentication	security.istio.io/v1	ra
EnvoyFilter	networking.istio.io/v1alpha3	ef
WorkloadEntry	networking.istio.io/v1	we

🎯 Final Exam Tips

⚙️ Installation

Know all profile differences
Restart pods after changing labels
Revisions for canary upgrades

🔀 Traffic

VirtualService = WHERE (routing)
DestinationRule = HOW (policy)
Weights must sum to 100

🔐 Security

Empty spec {} = deny all
Mesh-wide PA in istio-system
DENY → ALLOW → implicit deny

🔧 Troubleshoot

analyze → proxy-status → proxy-config
Know response flags (NR, UH, UO)
Check istio-proxy container logs

⏱️

Time Management (2-Hour Exam)

Installation (20%) — ~24 minutes
Traffic Management (35%) — ~42 minutes
Security (20%) — ~24 minutes
Troubleshooting (20%) — ~24 minutes
Review & Buffer — ~6 minutes

Istio Certified Associate

Installation & Configuration

Traffic Management

Securing Workloads

Troubleshooting

📘 About This Study Guide

🖥️ Lab Environment Options

Required Tools

🎯 Exam Overview & Format

Exam Strategy

Installation, Upgrade & Configuration

Installing Istio with istioctl

Pro Tip

Customizing Your Istio Installation

Understanding outboundTrafficPolicy

Sidecar Mode vs. Ambient Mode

Canary Upgrades

Important Upgrade Consideration

📋 Domain 1 Exam Checklist

🔑 Key Concepts to Memorize

Exam Scenario: Installation Troubleshooting

📚 Official Documentation References

Traffic Management

Setting Up the Practice Environment

Configuring Ingress with Gateway

Configuring Routing with VirtualService

Defining Traffic Policies with DestinationRule

Traffic Shifting (Canary Deployments)

External Services with ServiceEntry

Resilience: Timeouts, Retries, Circuit Breaking

Exam Focus: Where to Configure What

Fault Injection for Testing

📋 Domain 2 Exam Checklist

🔑 Key Concepts to Memorize

Exam Gotcha: VirtualService + DestinationRule

Common Exam Mistake: Traffic Weights

📚 Official Documentation References

Securing Workloads

Configuring mTLS with PeerAuthentication

Authorization with AuthorizationPolicy

JWT Authentication

Gateway TLS Configuration

📋 Domain 3 Exam Checklist

🔑 Key Concepts to Memorize

Exam Critical: Principal Formats

Common Exam Mistake: Empty Spec

📚 Official Documentation References

Troubleshooting

Configuration Analysis with istioctl analyze

Proxy Synchronization Status

Inspecting Proxy Configuration

Control Plane Troubleshooting

Common Issues Quick Reference

503 Errors After DestinationRule

NR (No Route) in Access Logs

UO (Upstream Overflow) Flag

Observability Tools

📋 Domain 4 Exam Checklist

🔑 Key Concepts to Memorize

Exam Troubleshooting Workflow

📚 Official Documentation References

⚡ Essential Commands Quick Reference

📝 API Resources Quick Reference

🎯 Final Exam Tips

⚙️ Installation

🔀 Traffic

🔐 Security

🔧 Troubleshoot

Time Management (2-Hour Exam)

You're Ready to Conquer the ICA Exam!