ICA — the exam

The Istio Certified Associate (ICA) is the CNCF and Linux Foundation's credential for the service mesh — the layer that takes encryption, identity, retries, timeouts and traffic shifting out of application code and turns them into things the platform configures instead. On this nine-certification shelf it is the odd one out in one precise way: every other associate here is pure multiple choice, and the ICA is hybrid — a proctored exam mixing real hands-on tasks at a command line with multiple-choice questions, in roughly two hours. That one fact should change how you prepare for it more than anything else on this page. What follows is the hub for that preparation: the four official domains and weights straight from the CNCF's published curriculum, a worked VirtualService + DestinationRule pair and a PeerAuthentication + AuthorizationPolicy pair — the two resource pairs you will be asked to write from memory — and the logistics worth checking before you register.

What the ICA is, and why the format is unusual

☺ Like you're 10: Most of this shelf is "answer questions about the rocket." This one is "answer questions about the rocket, then actually fly it for a bit."

The ICA certifies operational competence with Istio, the CNCF-graduated, Envoy-based service mesh — one project, examined deeply rather than a survey of many. The Linux Foundation lists it as an online, remote-proctored exam combining performance-based tasks solved at a real command line with multiple-choice items. It is neither a pure lab exam nor a pure paper exam; it sits between them, and the only other non-multiple-choice credential anywhere on this ladder is the fully performance-based LFCS. Every other project associate here — CGOA, CAPA, CBA, CCA, KCA, OTCA, PCA — is ninety minutes of pure multiple choice. The certifications hub has the full nine side by side if you want to see just how alone the ICA is on that axis.

There are no formal prerequisites, but Kubernetes fluency is assumed by nearly every task on the exam — you are expected to already know your way around a Deployment, a Service, and kubectl without thinking about it. This course does not re-teach that ground; it lives in full in the sibling Kubernetes course, and The Kubernetes Baseline You Need is the fastest way to check whether yours is solid enough to start here.

The four official domains and their weights

☺ Like you're 10: The test has four parts and they're not the same size — moving traffic around is worth more than a third of the whole grade, on its own.

These come straight from the CNCF's published Istio Certified Associate (ICA) Exam Curriculum — domain names, percentages and competency lists exactly as printed, not a paraphrase. Four domains, seventeen competencies, summing to exactly 35 + 25 + 20 + 20 = 100%. Bars below are drawn to scale against the largest domain:

Reading the shape of this blueprint

Three things stand out once the table is in front of you. Traffic management is more than a third of the exam by itself, with seven named competencies against security's three — if your Istio experience begins and ends with "we turned on mTLS," you're strong in a quarter of the paper and thin in over a third of it. Resilience is spelled out, feature by feature — circuit breaking, failover, outlier detection, timeouts, retries — inside the largest domain, and these are exactly the fields people never set by hand until an exam forces them to. Installation names both paths of everything: istioctl or Helm, sidecar or ambient, canary or in-place upgrade. Both halves of each pair are on the curriculum, so you don't get to learn a favorite and skip the rest.

Traffic management up close — the 35% that decides your result

☺ Like you're 10: One rulebook decides where a request goes. A second rulebook decides what happens to it once it gets there — how fast, how safely, and what to do if something's sick.

Two resources carry most of this domain, and the exam will make you write them together. A VirtualService decides where a request goes: match on host, header, path or method, then route, split traffic by weight, retry, time out, or inject a fault. A DestinationRule decides what happens after routing: named subsets plus a trafficPolicy covering load balancing, connection pools, and outlier detection. Weights inside one route must sum to 100, and naming a subset in a VirtualService that no DestinationRule defines is the single most common self-inflicted 503 on this exam.

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: mission-api
  namespace: launch
spec:
  host: mission-api.launch.svc.cluster.local
  subsets:
    - name: v1
      labels: { version: v1 }
    - name: v2
      labels: { version: v2 }
  trafficPolicy:
    loadBalancer: { simple: LEAST_REQUEST }
    connectionPool:                    # ---- circuit breaking ----
      tcp:  { maxConnections: 100 }
      http:
        http2MaxRequests: 200
        maxRequestsPerConnection: 10
    outlierDetection:                  # ---- eject unhealthy endpoints ----
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: mission-api
  namespace: launch
spec:
  hosts: ["mission-api"]               # short name = in-mesh (east-west) traffic
  http:
    - fault:                           # ---- fault injection ----
        delay: { percentage: { value: 5 }, fixedDelay: 3s }
      timeout: 2s                      # ---- timeout ----
      retries:                         # ---- retries ----
        attempts: 3
        perTryTimeout: 500ms
        retryOn: 5xx,reset,connect-failure
      route:                           # ---- traffic shifting: must total 100 ----
        - destination: { host: mission-api, subset: v1 }
          weight: 90
        - destination: { host: mission-api, subset: v2 }
          weight: 10

The rest of the domain lives at the mesh's edges. Ingress is a Gateway — a listener bound to a gateway deployment by pod labels — plus a VirtualService that names it in the gateways field; leave that field off and your rules apply only to in-mesh traffic, which is the classic "why is my route being ignored?" moment. Connecting to external workloads is a ServiceEntry, usually paired with outboundTrafficPolicy.mode: REGISTRY_ONLY so anything not explicitly declared can't leave the mesh at all. Study Istio and this course's own Service Mesh Architecture for the wider picture before drilling the YAML above until it comes out unaided.

Securing workloads — mTLS, JWT, and authorization

☺ Like you're 10: One rule checks whether a caller is wearing the mesh's own ID badge. A second rule checks whether that badge is actually allowed through this particular door.

Three competencies, and it rewards knowing exactly which resource answers which question. PeerAuthentication answers "must the caller present a mesh certificate?" — workload identity, with mode: STRICT as the zero-trust setting. RequestAuthentication answers "is this end user's JWT valid, and who issued it?" — on its own it rejects only invalid tokens, never missing ones. AuthorizationPolicy answers "is this caller allowed to do this, specifically?" and is where both identities actually get enforced. Edge TLS is a Gateway with tls.mode: SIMPLE or MUTUAL plus a credentialName pointing at a Secret in the gateway's own namespace.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: launch          # in istio-system with no selector = mesh-wide
spec:
  mtls:
    mode: STRICT              # STRICT | PERMISSIVE | DISABLE | UNSET
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-flight-console
  namespace: launch
spec:
  selector:
    matchLabels: { app: mission-api }
  action: ALLOW
  rules:
    - from:
        # keys INSIDE one source are ANDed; separate `- source:` blocks are ORed
        - source:
            principals:               # workload identity (SPIFFE), not an IP
              - cluster.local/ns/launch/sa/flight-console
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/telemetry*"]
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: launch
spec:
  {}                          # empty spec, action defaults to ALLOW with zero
                               # rules => nothing at all is permitted. Know this cold.

Three rules matter more than any single field. Evaluation runs CUSTOM → DENY → ALLOW, so a matching DENY always beats any ALLOW. The moment any ALLOW policy selects a workload, that workload becomes default-deny for everything not explicitly permitted — which is exactly why the empty-spec policy above locks a namespace down completely. And within one block the keys are ANDed, but separate list entries are ORed — splitting a caller's service identity and its JWT requirement into two separate - source: entries silently turns "identity and valid token" into "identity or valid token," which is a hole, not a policy.

Installation, upgrades, and the ambient question

☺ Like you're 10: There are two ways to put the mesh in, and two ways to upgrade it once it's there — and the exam wants you comfortable with both sides of each choice.

istioctl install is the fast route, built around profiles (default, demo, minimal, ambient) customized with --set or an IstioOperator-shaped file. Helm is the composable route: three charts installed in order — base for CRDs, istiod for the control plane, then gateway per ingress or egress gateway — which is what most GitOps setups use, because the mesh then arrives through the same reconciler as everything else. Sidecar mode injects an Envoy proxy into every pod; ambient mode moves that job to a per-node ztunnel plus cni chart instead, and enrolling a namespace in one mode versus the other uses different labels entirely.

The upgrade competency names two strategies, and the exam wants a clean one-sentence answer for each. In-place replaces the running control plane directly — simple, all-or-nothing. Canary installs a second istiod under a named revision and moves namespaces onto it one at a time by relabeling and restarting, with a revision tag as a stable alias you can repoint to move a whole fleet at once.

# --- Always run this first ---
istioctl x precheck

# --- Path A: istioctl, profile, then customized ---
istioctl install --set profile=default -y
istioctl install --set profile=ambient -y                # ztunnel + CNI agent
istioctl profile diff default demo                       # what a profile changes

# --- Path B: Helm, three charts, in this order ---
helm repo add istio https://istio-release.storage.googleapis.com/charts
helm install istio-base istio/base -n istio-system --create-namespace
helm install istiod     istio/istiod -n istio-system --wait
helm install istio-ingressgateway istio/gateway -n istio-ingress --create-namespace

# --- Enrol a namespace: pick ONE mode, they are mutually exclusive ---
kubectl label namespace launch istio-injection=enabled   # sidecar, default rev
kubectl label namespace launch istio.io/dataplane-mode=ambient
kubectl rollout restart deployment -n launch              # sidecars need a restart

# --- Upgrade: canary (revisions) vs in-place ---
istioctl install --set revision=1-27-0 -y                 # second control plane
istioctl tag set launch-stable --revision 1-27-0           # stable alias for a fleet
kubectl label ns launch istio.io/rev=1-27-0 --overwrite    # move ONE namespace
kubectl rollout restart deployment -n launch                # ...and restart it

istioctl upgrade -y                                        # in-place: all at once

Two details cost people tasks under time pressure. Injection happens only at pod creation, so existing pods are never retrofitted — always restart after relabeling. And if both istio-injection=enabled and istio.io/rev are present on a namespace, the plain label wins, so remove it before moving that namespace onto a revision.

Troubleshooting — the three-layer ladder

☺ Like you're 10: If something's broken, check three things in order — is the rule written correctly, did the rule actually reach the right place, and is the one proxy in question actually following it?

The final 20% splits into exactly the three things that can be wrong, named in a useful order: your configuration, the control plane, the data plane. Work them in that order and most failures fall out fast. istioctl analyze is a genuinely good linter — missing subsets, conflicting policies, unreferenced gateways — and catches most configuration mistakes before they ever become a 503.

# 1. CONFIGURATION — lint before you blame anything else
istioctl analyze -n launch

# 2. CONTROL PLANE — is istiod healthy, and did the push land?
kubectl -n istio-system get pods
istioctl proxy-status                # alias: ps. All columns SYNCED?
                                      # STALE = push stuck · NOT SENT = nothing to send

# 3. DATA PLANE — what does ONE proxy actually believe?
istioctl proxy-config route    mission-api-7d9f-abcde.launch --name 8080
istioctl proxy-config cluster  mission-api-7d9f-abcde.launch
istioctl proxy-config endpoint mission-api-7d9f-abcde.launch \
  --cluster "outbound|8080|v2|mission-api.launch.svc.cluster.local"
istioctl proxy-config secret   mission-api-7d9f-abcde.launch   # did the cert arrive?

# Plain-English summary: mTLS mode, policies and routes for one pod
istioctl x describe pod mission-api-7d9f-abcde.launch

Learn the symptoms that map to a single cause, because recognition beats deduction under a clock. RBAC: access denied is an AuthorizationPolicy, not a network fault. 503 with NO_HEALTHY_UPSTREAM means the cluster exists but has no endpoints; a fresh 503 right after a routing change usually means a subset the VirtualService names and no DestinationRule defines. Failures right after flipping a namespace to STRICT mean something outside the mesh is calling in — an unlabeled namespace, a probe, a client hitting a pod IP directly. A pod with no sidecar at all is almost always a namespace label applied after the pod was already running.

Exam logistics — and how to verify them

☺ Like you're 10: It's an online test you sit at home while someone watches through your webcam. Prices and timings change, so always check the official page before you pay for anything.

Some facts about the ICA are structural and safe to state. Others are exactly the sort the Linux Foundation revises without much announcement, and this table keeps the two apart on purpose.

↗ Official ICA page — Linux Foundation ◆ CNCF certification page ◆ Official CNCF curriculum repository ◆ Istio documentation

Where it sits in the ladder, and what to do next

☺ Like you're 10: This is a specialist badge, not a starter one. From here you either drill the same four domains harder, or go build the real thing.

Despite the "Associate" name, treat the ICA as a specialist credential rather than an entry-level one — its hands-on half puts it closer in spirit to the Kubernetes course's own CKA and CKS than to a pure knowledge quiz. It gates nothing on this ladder and nothing gates it, but the Kubernetes fluency it assumes is real. If a deeper look at how Istio fits into a broader platform-engineering role is what you actually need next, Platform Engineering's own ICA page maps the same exam against the CNPE's Security & Policy domain.

Inside this course, continue with the ICA study plan, then drill with the practice tasks & questions and three timed papers — Mock Exam · Set 1, Set 2, and Set 3. For the architecture underneath the whole exam, read Service Mesh Architecture; for a guided hands-on rep before exam day, run the Lock Down a Mesh Namespace drill.