ICA — Istio Certified Associate

The Istio Certified Associate (ICA) is the CNCF and Linux Foundation’s credential for the service mesh — the layer that takes encryption, identity, authorization, retries, timeouts and traffic shifting out of every application and makes them things the platform provides by configuration. Read its curriculum and one thing is obvious: every competency is a verb. Installing. Configuring. Upgrading. Troubleshooting. This is not principally an exam about what a mesh is; it is an exam about whether you can make one behave. Here: the four official domains and weights, the substance behind each, whether it earns a place in your year, and a study route built from this site.

What the ICA is — and who it is for

☺ Like you’re 10: It’s mostly a hands-on test. They give you a real cluster with a real mesh on it and a list of jobs, and you have to actually do them — plus some pick-the-right-answer questions mixed in.

The ICA certifies operational competence with Istio, the CNCF-graduated, Envoy-based service mesh. Its scope is deliberately narrow — one project, four domains — and correspondingly deep. Where a broad exam asks you to recognise that a mesh provides mTLS, the ICA asks you to install the mesh, enrol a namespace, flip it to STRICT, write the AuthorizationPolicy that permits exactly one ServiceAccount, and then work out why a request that should be allowed returns RBAC: access denied.

Verbs, not vocabulary

Compare it to a knowledge-based exam like the CGOA, whose competencies are nouns — Desired State, State Drift, Rollback — because it tests definitions. Every ICA competency is an action on a running system. The Linux Foundation’s listing describes the ICA as an online, proctored, performance-based and multiple-choice exam — a hybrid, and an unusual one. Most CNCF “Associate” credentials (KCNA, KCSA, CGOA, CAPA) are purely knowledge-based multiple choice, while the hands-on tier is CKA, CKAD, CKS and the CNPE. The ICA straddles the two: it carries the Associate name and a multiple-choice component, but it also puts you at a command line against a live cluster. Do not prepare for it as if it were either one alone. Study accordingly: reading about outlierDetection is not the same skill as having written it under a clock — and neither substitutes for knowing which resource owns which field when the question is a list of four options.

Who should sit it

• Platform engineers who already run, or are about to run, a mesh for other teams — this credential matches that job most exactly.
• Network and connectivity specialists moving from load balancers and firewalls into identity-aware, L7 policy.
• Security engineers who own “is all internal traffic encrypted, and who may call what?” and want to answer with enforcement rather than a spreadsheet.
• SREs and release engineers driving mesh canaries with Flagger or Argo Rollouts, currently trusting a controller to write weights they cannot read.

Why a platform engineer would take it — and when to skip it

☺ Like you’re 10: If you run a mesh, this badge is basically your job written down. If you don’t run one — and might never — it’s a lot of work for a skill you won’t use.

Be honest about the return. The ICA is the most situational certification on the cloud-native shelf: enormously valuable if a mesh is in your future, close to worthless if it isn’t. That is unusual — CKA or CNPA pay off almost regardless of where you work — and it should drive your decision more than anything else.

Where it pays off, and how it maps to the CNPE

Istio is named on the official CNPE tool list and lands hardest in the CNPE’s Security & Policy Enforcement domain: workload identity, mTLS, identity-aware authorization. It also carries weight in GitOps & Continuous Delivery — weighted routing is the mechanism under every mesh canary — and touches Observability and Platform Architecture. But the sizing matters: the mesh is part of a 15% domain, not a domain of its own, and the CNPE also wants Kyverno, Gatekeeper, RBAC, supply-chain security and secrets. The ICA takes you far past anything the CNPE will ask — a feature if you operate a mesh for a living, a waste of weeks if you are simply trying to pass the CNPE.

When to skip it

Skip it if any of these are true. You have no mesh and no mandate to add one — plenty of good platforms run NetworkPolicy, a solid ingress and cert-manager, and are right to. Your mesh is Linkerd or Cilium — concepts transfer, but the exam tests Istio’s specific APIs and CLI, and there is a dedicated Cilium credential for that datapath. You need one certification for a job filter — recruiters screen on CKA and increasingly on CNPE. You are new to Kubernetes — the exam assumes fluency with Services, Deployments and kubectl, so the substrate lesson plus a CKA is the better sequence. Take it if you own connectivity or security for a real estate of services; the certifications overview shows where it sits against everything else.

The four official domains & their weights

☺ Like you’re 10: The test has four parts and they’re not equal. Moving traffic around is more than a third of the whole thing.

These come straight from the CNCF’s published Istio Certified Associate (ICA) Exam Curriculum — the domain names, the percentages and the competency lists below are that document, not a paraphrase. Four domains, 35 + 25 + 20 + 20 = 100%, seventeen competencies between them. The bars are drawn to scale:

Every competency, domain by domain

The full curriculum — four domains, seventeen competencies, exactly as the CNCF publishes them, with the pages here that cover each:

Reading the shape of this blueprint

Three things jump out. First: traffic management is more than a third of the exam on its own, with seven competencies where security has three. If your Istio experience is mostly “we turned on mTLS,” you are strong in 25% of the paper and thin in 35% of it. Reverse that.

Second: resilience is called out explicitly, its parts named in the curriculum itself — circuit breaking, failover, outlier detection, timeouts, retries. These are the fields people skim because they rarely set them by hand, and they sit inside the largest domain. Reliability & incidents gives the why; the DestinationRule below gives the where.

Third: installation names both install paths and both data planes. istioctl or Helm; sidecar or ambient; canary or in-place upgrade. Both sides of each pair are listed, so you don’t get to pick a favourite and ignore the rest.

What you actually need to know

☺ Like you’re 10: Here’s the real substance — moving traffic, locking it down, putting the mesh in place, and finding out what broke.

Traffic management — the 35% that decides your result

Two resources do most of the work, 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 by weight, retry, time out, mirror or inject a fault. A DestinationRule decides what happens after routing: named subsets plus a trafficPolicy — load balancer, connection pools, outlier detection, TLS mode. Weights in a route must sum to 100, and a subset a VirtualService names but no DestinationRule defines is a 503 — the commonest self-inflicted wound here.

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: checkout
  namespace: prod
spec:
  host: checkout.prod.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
        http1MaxPendingRequests: 32 # queue depth before requests are shed
    outlierDetection:               # ---- eject unhealthy endpoints ----
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: checkout
  namespace: prod
spec:
  hosts: ["checkout"]               # short name = in-mesh (east-west) traffic
  http:
    - match:                        # header-based routing beats weights for testing
        - headers:
            x-canary: { exact: "true" }
      route:
        - destination: { host: checkout, subset: v2 }
    - fault:                        # ---- fault injection ----
        delay:  { percentage: { value: 5 },  fixedDelay: 3s }
        abort:  { percentage: { value: 1 },  httpStatus: 503 }
      timeout: 2s                   # ---- timeout ----
      retries:                      # ---- retries ----
        attempts: 3
        perTryTimeout: 500ms
        retryOn: 5xx,reset,connect-failure
      route:                        # ---- traffic shifting: must total 100 ----
        - destination: { host: checkout, subset: v1 }
          weight: 90
        - destination: { host: checkout, subset: v2 }
          weight: 10

The remaining competencies are the mesh’s edges. Ingress is a Gateway (a listener bound to a gateway deployment by pod labels) plus a VirtualService naming it in the gateways field — omit that field and your rules apply only to in-mesh traffic, the classic “why is my route ignored?” The project’s stated direction is the vendor-neutral Gateway API (Gateway + HTTPRoute, gatewayClassName: istio), so write both forms. External services are a ServiceEntry, paired with outboundTrafficPolicy.mode: REGISTRY_ONLY — set mesh-wide in MeshConfig, or narrowed to selected workloads on a Sidecar resource — so that anything not declared as a ServiceEntry cannot leave. Locality failover is the one people misplace: it is trafficPolicy.loadBalancer.localityLbSetting on a DestinationRule, nested inside loadBalancer, not a sibling of it, and it needs outlierDetection configured before it will shift anything. Networking & service connectivity gives the wider context.

Securing workloads — mTLS, JWT and authorization

Three competencies, four resources, and it rewards precision about which resource answers which question. PeerAuthentication answers “must the caller present a mesh certificate?” — workload authentication, with mode: STRICT as the zero-trust setting. RequestAuthentication answers “is this JWT valid, and who issued it?” — end-user authentication, which on its own rejects only invalid tokens, never absent ones. AuthorizationPolicy answers “is this caller allowed to do this?” Edge TLS is a Gateway with tls.mode: SIMPLE (or MUTUAL) plus a credentialName naming a Secret in the gateway’s own namespace.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: prod          # in istio-system with no selector = mesh-wide
spec:
  mtls:
    mode: STRICT           # STRICT | PERMISSIVE | DISABLE | UNSET
---
apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: jwt-issuer
  namespace: prod
spec:
  selector:
    matchLabels: { app: checkout }
  jwtRules:
    - issuer: "https://accounts.example.com"
      jwksUri: "https://accounts.example.com/.well-known/jwks.json"
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-jwt-and-frontend
  namespace: prod
spec:
  selector:
    matchLabels: { app: checkout }
  action: ALLOW
  rules:
    - from:
        # Keys INSIDE one source are ANDed; separate `- source:` entries are ORed.
        # Both keys here: caller must be the frontend SA *and* carry a valid JWT.
        - source:
            principals:              # workload identity (SPIFFE), NOT an IP
              - cluster.local/ns/prod/sa/frontend
            requestPrincipals:       # end-user identity: "<issuer>/<subject>"
              - "https://accounts.example.com/*"
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/cart*"]
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: prod
spec:
  {}                                 # empty spec = ALLOW with zero rules
                                     # => nothing is permitted. Know this cold.

Three evaluation rules matter more than any field. Policies are evaluated in the order CUSTOM → DENY → ALLOW, so a matching DENY wins outright over any ALLOW. If any ALLOW policy selects a workload, that workload becomes default-deny for everything not explicitly permitted. And the boolean structure is easy to get backwards: within one source, from, to or when block the keys are ANDed; separate list entries under from or to are ORed; and separate entries under rules are ORed too. Splitting principals and requestPrincipals into two - source: entries — the commonest way to write the policy above — silently turns “service identity and valid token” into “service identity or valid token”, which is a hole rather than a policy. That first asymmetry is why the empty-spec policy above locks down a namespace, and why adding your first ALLOW to a busy service is an outage unless you have enumerated its callers. action: AUDIT logs what would have been denied, so roll out PERMISSIVE before STRICT and AUDIT before DENY, every time. Security & policy enforcement sets this beside RBAC and admission control; secrets management covers the gateway’s TLS Secret.

Installation, customisation and the canary upgrade

istioctl install is the fast route and takes built-in profiles (default, demo, minimal, ambient) customised with --set or an IstioOperator-shaped file. Helm is the composable route: three charts in order — base (CRDs and cluster roles), istiod, then gateway per ingress or egress gateway — and it is what most GitOps setups use, because the mesh then arrives through the same reconciler as everything else. Ambient adds the cni and ztunnel charts.

The upgrade competency names two strategies; separate them in one sentence each. In-place replaces the running control plane — simple, all-or-nothing. Canary installs a second istiod under a revision, moves namespaces onto it one at a time by changing the istio.io/rev label and restarting their pods, and rolls back by relabelling. Revision tags (a stable alias like prod-stable pointing at 1-27-0) move a whole fleet by repointing the tag.

# --- Will this cluster take Istio? Always run this first. ---
istioctl x precheck

# --- Path A: istioctl, with a profile, then customised ---
istioctl install --set profile=default -y
istioctl install --set profile=ambient -y                  # ztunnel + CNI agent
istioctl install -f my-mesh.yaml -y                        # IstioOperator-shaped file
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, they are mutually exclusive ---
kubectl label namespace prod istio-injection=enabled       # sidecar, default rev
kubectl label namespace prod istio.io/rev=1-27-0           # sidecar, revisioned
kubectl label namespace prod istio.io/dataplane-mode=ambient
kubectl rollout restart deployment -n prod                 # sidecars need a restart

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

istioctl upgrade -y                                        # in-place: all at once
istioctl version                                           # client, istiod, proxies

Three details cost people tasks. Injection happens only at pod creation, so existing pods are never retrofitted — always restart. If both istio-injection=enabled and istio.io/rev are present the plain label wins, so remove it (kubectl label ns prod istio-injection-) before moving to a revision. And after a canary upgrade, istioctl proxy-status tells you which proxies still talk to the old control plane. Helm and GitOps workflows cover the delivery mechanics.

Troubleshooting — the ladder from control plane to proxy

The last 20% splits into the three things that can be wrong, and the curriculum names them 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 and catches most configuration errors — missing subsets, conflicting policies, unreferenced gateways, unlabelled namespaces — before they become a 503. For the control plane, check istiod is healthy and that its config actually reached the proxies: istioctl proxy-status should read SYNCED in every column, where STALE means a push is stuck and NOT SENT means istiod has nothing to send. For the data plane, ask one proxy what it believes.

# 1. CONFIGURATION — lint before you blame anything else
istioctl analyze -n prod
istioctl analyze virtualservice.yaml destinationrule.yaml   # even before committing

# 2. CONTROL PLANE — is istiod healthy, and did the push land?
kubectl -n istio-system get pods
kubectl -n istio-system logs deploy/istiod
istioctl proxy-status            # alias: ps. CDS/LDS/EDS/RDS all SYNCED?
                                 # STALE = push stuck · NOT SENT = nothing to send

# 3. DATA PLANE — what does ONE proxy actually believe?
istioctl proxy-config route    checkout-7d9f-abcde.prod --name 8080 -o json
istioctl proxy-config cluster  checkout-7d9f-abcde.prod
istioctl proxy-config endpoint checkout-7d9f-abcde.prod \
  --cluster "outbound|8080|v2|checkout.prod.svc.cluster.local"
istioctl proxy-config listener checkout-7d9f-abcde.prod --port 15006
istioctl proxy-config secret   checkout-7d9f-abcde.prod   # did the cert arrive?

# Plain-English summary: mTLS mode, policies and routes affecting one pod
istioctl x describe pod checkout-7d9f-abcde.prod

# Turn up Envoy logging, then read what the proxy recorded
istioctl proxy-config log checkout-7d9f-abcde.prod --level rbac:debug,router:debug
kubectl logs checkout-7d9f-abcde -n prod -c istio-proxy

Learn the symptoms that map to a single cause, because under time pressure recognition beats deduction. RBAC: access denied is an AuthorizationPolicy, not a network problem. 503 with NO_HEALTHY_UPSTREAM means the cluster exists but has no endpoints; a 503 right after a routing change usually means a subset the VirtualService names and no DestinationRule defines. Failures right after enabling STRICT mean something outside the mesh is calling in — an unlabelled namespace, a scraper, a probe, a client using a pod IP. A pod with no sidecar is almost always a namespace label applied after the pod was created. The same ladder from the packet upward is Triage: networking, with the general method in the troubleshooting playbook.

How to prepare using this site

☺ Like you’re 10: Every part of this test already has a page here. Read them in weight order, then go and actually type everything.

This course was written for the CNPE, but its mesh, networking and security material lines up closely with the ICA blueprint. Study in weight order — traffic management first, because it is 35% and because routing is what every other domain is expressed in terms of — and pair every page with hands on a real cluster. Reading is preparation for practising, not a substitute for it.

Domain-by-domain study map

A four-week pace

Four weeks is realistic for an engineer who has used Istio; stretch to six if the mesh is new, and add a CKA-level refresher first if kubectl isn’t already automatic.

Exam logistics — and how to verify them

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

Some facts about the ICA are structural and safe to state; others are exactly the sort the Linux Foundation revises without announcement. This page separates them deliberately.

What can be stated with confidence

What you must check on the official page

Two things are never published at all. The item count is not stated — candidate write-ups cluster around fifteen to twenty items in the two hours, but that is community anecdote, not a specification, and mixed formats make it a poor thing to plan around anyway. The pass mark is not stated on the listing either; figures circulate on study blogs, they are unofficial, and the only safe target is “comfortably above whatever you have read.” Beyond those, the numbers that genuinely move are price, duration, retake policy, eligibility window, certification validity, the Istio version tested, and the permitted documentation. The figures in the table above were taken from the official listing when this page was written; the CNCF also discounts often enough that the sticker price is rarely what people pay, so check the current one rather than budgeting from here.

The permitted-documentation rule deserves its own look. Linux Foundation hands-on exams generally allow one extra browser tab on the product’s own documentation, which for a mesh exam is the difference between memorising outlierDetection’s field names and merely knowing where they live. Read the current candidate handbook for the exact allowed domains and the rules on copy-paste — and practise with only that one tab open, because searching istio.io quickly is itself an exam skill.

↗ 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 go deeper into connectivity or wider across the platform.

Despite the name, treat the ICA as a specialist credential rather than an entry-level one. It carries “Associate” because it covers one project, not because it is easy, and its hands-on half puts it far closer to CKS than to KCNA. It gates nothing and nothing gates it, but Kubernetes fluency is a real practical prerequisite. The certifications overview lays out the whole shelf.

Go wider — the platform around the mesh

The natural sequel is the exam that puts the mesh in context: the CNPE, where Istio is one tool among many and the job is assembling a platform rather than tuning a proxy. You already own a chunk of its Security & Policy domain and its traffic shifting; what remains is GitOps, platform APIs, observability and architecture. Start with the lab track, then the practice task bank, then a timed mock exam. For breadth on the connectivity side, the Cilium credential covers the datapath beneath the mesh and CKS the cluster security around it.

Go build

Certifications reward reps, and these reps are also good platform work. Put your mesh configuration under a reconciler so VirtualService and AuthorizationPolicy arrive through GitOps like everything else. Wire a real canary with Flagger so the weights you learned to write by hand are driven by metrics instead. Add a policy refusing any production namespace without a PeerAuthentication. Point Grafana at the mesh’s golden signals. And when traffic misbehaves, start where you always should — Triage: networking, with Know It Cold beside you.