ICA Study Plan

The ICA blueprint lays out the four official domains, their weights, and the two resource pairs — VirtualService + DestinationRule, PeerAuthentication + AuthorizationPolicy — you'll be asked to write from memory. This page turns that into a calendar. Four weeks, twenty-one study days, and a day count derived straight from the published weights instead of an even four-way split: Traffic Management is 35% of the exam — worth more than Securing Workloads and Troubleshooting combined — and it claims the widest block on the schedule below, spanning most of weeks one and two. But day count alone isn't the whole story here, because the ICA is the one hybrid credential on this entire shelf. Every domain in this plan also carries an hours-on-a-keyboard budget, because a performance-based exam does not reward a candidate who has only ever read about a DestinationRule. Add up all four domains and roughly two-thirds of this plan's total hours are spent hands-on a real cluster, not a screen of prose.

Twenty-one days, weighted like the exam — not the calendar

☺ Like you're 10: Don't give every domain the same number of days, and don't spend all your time reading either. Give the big domain more days, and give every domain more hands-on time than reading time.

The CNCF publishes four weighted domains for the ICA, and this plan does nothing cleverer than turning that percentage straight into a day count and an hours budget. Read the full domain table and competency list on the ICA blueprint first if you haven't already — this page assumes you already know roughly what each domain covers and spends its words purely on pacing it, and on how much of that pacing happens with your hands on a keyboard.

hours for a domain = total domain-study hours × that domain's weight.

This plan spends 30 hours of domain study across twenty study days — a little over seven hours a week, realistic for an exam that puts you at a real command line, not the lighter load a pure knowledge test needs. Applying that formula to the four published weights, and splitting each domain's hours into keyboard time versus reading time:

Before day one — the Kubernetes you need already, and picking your pace

☺ Like you're 10: Twenty-one days is a guess that fits most people who already know their way around a cluster. If Kubernetes itself is still new, give yourself more runway before you start the clock on this plan.

The ICA lists no formal prerequisite, but nearly every task on the exam assumes you already move through kubectl, a Deployment and a Service without thinking about it — this plan does not re-teach that ground. If any of it is still shaky, this course's own Kubernetes Baseline You Need or the sibling Kubernetes course's CKA track is worth a detour before day one here.

The 21-day schedule at a glance

☺ Like you're 10: Here's the whole four weeks on one strip — which days belong to which domain, sized by how much of the test they're actually worth.

The bar below is the table that follows it, drawn to scale. Block width is day count, not domain count — Traffic Management's block alone is nearly a third of the entire strip, the same claim its 35% weight makes on the real paper. Installation opens the plan even though it isn't the biggest domain, for one practical reason: nothing else in weeks two through four can be practiced hands-on without a mesh already running.

Days 1–4 — Install, Upgrades & Configuration, the foundation everything else needs

☺ Like you're 10: Before you can practice steering, someone has to put the ship on the launch pad. That's week one — and it's a fifth of the real exam too, not just a warm-up.

This plan opens with the smallest-tied domain (20%) instead of the biggest one, and the reason is purely practical: none of the traffic, security or troubleshooting practice in weeks two through four works without a mesh already installed and a namespace already enrolled in it. Install with istioctl first — the fast route, built on profiles (default, demo, minimal, ambient) customized with --set or an IstioOperator-shaped file — then tear the cluster down and reinstall with Helm's three charts in order: base for CRDs, istiod for the control plane, gateway per ingress or egress gateway. Doing both is the point; the exam names both paths, and most GitOps setups use Helm precisely because the mesh then arrives through the same reconciler as everything else.

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

# --- Path A: istioctl, a profile, then customized ---
istioctl install --set profile=demo -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

# --- Then a full canary upgrade, revisions AND tags — don't skip this ---
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
istioctl proxy-status                                        # confirm it actually moved

Days 5–11 — Traffic Management, the 35% that decides your result

☺ Like you're 10: Almost forty cents of every dollar this exam is worth lives in two resources working together: one that decides where a request goes, and one that decides what happens to it once it gets there.

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 one route must sum to 100, and a subset a VirtualService names but no DestinationRule defines is a 503 — the single most common self-inflicted wound on this domain. Write this pair from memory on Days 5–7, then diff your version against the reference below field by field:

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
        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: mission-api
  namespace: launch
spec:
  hosts: ["mission-api"]               # short name = in-mesh (east-west) traffic
  gateways: ["mesh"]                   # omit this and edge rules never apply here
  http:
    - fault:                           # ---- fault injection, Day 9 ----
        delay: { percentage: { value: 5 }, fixedDelay: 3s }
        abort: { percentage: { value: 1 }, httpStatus: 503 }
      timeout: 2s                      # ---- timeout, Day 8 ----
      retries:                         # ---- retries, Day 8 ----
        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

Days 10–11 move to 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 (or forget it defaults to mesh for in-cluster traffic only) and edge rules never take effect, the classic "why is my route being ignored?" The project's stated direction is the vendor-neutral Gateway API (Gateway + HTTPRoute, gatewayClassName: istio), so practice writing both forms of the same route. For workloads outside the mesh, a ServiceEntry registers them as if they were in it, usually paired with outboundTrafficPolicy.mode: REGISTRY_ONLY so anything not explicitly declared simply cannot leave.

Days 12–16 — Securing Workloads, the 25%

☺ 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. Learning which rule answers which question is most of this domain.

PeerAuthentication answers "must the caller present a mesh certificate?" — workload identity, with mode: STRICT 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 is where both identities actually get enforced.

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:` entries are ORed.
        # Both keys here: caller must be the flight-console SA *and* carry a valid JWT.
        - source:
            principals:               # workload identity (SPIFFE), NOT an IP
              - cluster.local/ns/launch/sa/flight-console
            requestPrincipals:        # end-user identity: "/"
              - "https://accounts.mission.example.com/*"
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/telemetry*"]
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: launch
spec:
  {}                          # empty spec = ALLOW with zero rules
                               # => nothing is permitted. Know this cold.

Days 17–21 — Troubleshooting, the readiness gate, and the mock

☺ 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 this one proxy 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 — this is also the domain with the highest hands-on share (75%) on this plan's budget, because recognizing a symptom under time pressure is a reflex you build by breaking things on purpose, not a fact you memorize.

# 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 on Day 20, 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. A pod with no sidecar at all is almost always a namespace label applied after the pod was already running — the same mistake from Days 1–4, showing up two weeks later.

Day 21 is the gate. Don't open Mock Exam · Set 1 until every box below is honestly true, not "true if I squint":

• ① The 35% — Traffic Management alone
• I can write a VirtualService + DestinationRule pair from a blank page, weights summing to 100
• I can name all five resilience features and which resource owns each one
• ② The remaining three domains
• I have done a full canary upgrade with revisions and tags, not just an in-place one
• I can write PeerAuthentication, RequestAuthentication and a deny-all AuthorizationPolicy unaided, and explain the AND/OR trap
• I can run the three-step troubleshooting ladder and name the failure each step's tool catches
• ③ The whole exam
• At least 60% of my study hours this month were hands-on a real cluster, not reading
• I have read the current official ICA candidate handbook, not just this page

Five or more checked, spanning all three categories, is a reasonable green light. Fewer than that, don't force the calendar — return to the specific day range above, not a general re-read of everything. Once clear, work the ICA practice tasks & questions, then sit Mock Exam · Set 1 under real conditions — clock running, one documentation tab if that's what the current handbook permits, nothing else. If it's close but not comfortable, hold your booking, spend one more evening on whichever domain the mock exposed, and sit Set 2 and Set 3 before committing a date. One score near the line is noise; two or three consistent scores above it is signal.