ICA Mock Exam · Set 1

This is your first full sitting of the ICA in this course's own format: 17 items in one unbroken 120-minute block — nine hands-on tasks worked at a real command line against a live mesh, and eight multiple-choice questions — weighted to the four official domains in the same proportion the CNCF weights them: Traffic Management 35%, Securing Workloads 25%, Installation, Upgrades & Configuration 20%, Troubleshooting 20%, exactly as the ICA blueprint lays them out. Every task carries a done when check and a folded worked solution; every question carries a folded explanation. Hands-on work carries the majority of this paper's points — 69 of 100 — because that's where a hybrid exam actually spends most of its own effort, even though the Linux Foundation doesn't publish the exact split. This is Set 1 of three; Set 2 and Set 3 stay sealed until you've fixed whatever this one exposes. If you haven't worked through the blueprint, the study plan, and the untimed practice bank yet, start there — this paper measures whether that prep survives a clock and a real cluster, not whether you've read about Istio.

Where Set 1 sits in your ICA prep

☺ Like you're 10: First you learn the mesh piece by piece, then you drill loose jobs and questions about it, and only then do you sit the whole timed test with everything mixed together.

The natural sequence on this course is: read the ICA blueprint for the four domains, their real weights, and the resource pairs the exam actually tests; follow the study plan's build-it-from-memory drills; work the untimed practice bank until nothing there surprises you; and only then sit this paper as your first honest measurement of all four domains at once, under a clock, on a real cluster. This paper assigns points to each domain in the exact proportion the CNCF assigns them — 35% Traffic Management, 25% Securing Workloads, 20% Installation, 20% Troubleshooting — so a weak score in one domain here is unusually actionable: it names precisely which section of the blueprint to reread, not just that you "did badly" in some vague sense.

Sit it like the real thing

☺ Like you're 10: No notes, no open tabs, one sitting, go — and a hands-on job only counts once it actually works, not once it looks finished.

The ICA is online, remote-proctored, and hybrid — performance-based tasks at a command line, mixed with multiple-choice items, in roughly two hours. Sit this practice paper under the same restriction: close every other tab, work the 17 items below exactly as you would a locked-down sitting, and for the hands-on tasks specifically, don't call one "done" until its done when check actually passes against your cluster. For the multiple-choice items, read the stem once, commit to an answer, and only then open the explanation underneath it — peeking first turns a diagnostic into a comprehension exercise and tells you nothing about whether you'd have gotten there cold. As on the real exam, never leave a multiple-choice item blank: eliminate what you can and commit to your best remaining option, since the Linux Foundation doesn't publish a separate penalty for a wrong guess beyond simply not earning the point.

Pre-flight — build the mesh cluster the night before

☺ Like you're 10: Set up your whole toolbox the day before, so that when the clock starts you're already holding the screwdriver, not still looking for it.

A throwaway kind or minikube cluster is enough. Install Istio with the demo profile, which brings the ingress and egress gateways along with the control plane, then deploy a small two-version service to route against. Confirm everything is healthy before the timer starts — if something turns out to be missing mid-sitting, skip the item and move on, never stop the clock to fix your environment, because the real exam won't let you either.

# --- the night before -------------------------------------------------
kind create cluster --name ica-mock1
istioctl install --set profile=demo -y
kubectl get pods -n istio-system                     # istiod + both gateways Running

kubectl create namespace orbit
kubectl label namespace orbit istio-injection=enabled
kubectl apply -n orbit -f telemetry-api-v1-v2.yaml    # your own two-version Deployment+Service
kubectl apply -n orbit -f ground-console-client.yaml  # a curl-capable pod, SA: ground-console
kubectl apply -n orbit -f weather-sync-client.yaml    # a second curl-capable pod, SA: weather-sync
kubectl -n orbit get pods                             # every app pod should read 2/2 (sidecar injected)

# --- ninety seconds before the clock starts ---------------------------
kubectl config set-context --current --namespace=orbit
kubectl config view --minify -o jsonpath='{..namespace}{"\n"}'   # say it out loud
istioctl analyze -n orbit                              # clean baseline before you touch anything

Your 120-minute budget

☺ Like you're 10: Give every job and every question a small slice of the two hours, weighted by how big a piece of the exam it stands in for.

Seventeen items in 120 minutes is not an even split, and it shouldn't be — a ten-point hands-on task earns a bigger slice of the clock than a three-point question. Allocate 5 minutes to read the whole paper first, 102 minutes of item work, and 13 minutes at the end to re-run every done-when check. That last block earns more points per minute than anything else on the paper, because a hands-on task you never verified scores exactly the same as one you never attempted.

The paper — 17 items across four domains

☺ Like you're 10: Nine real jobs on a real cluster, eight pick-the-right-answer questions, all sorted into the same four groups the real exam sorts them into.

Every item is tagged with its domain and its type — the real exam won't hand you that label quite so plainly, but it helps you total your score afterward and decide where to spend the fortnight after you mark this paper. Read a task's brief and its done when check, work it against your cluster, then open the folded solution only once you've genuinely attempted it. For the multiple-choice items, pick an answer before you look.

🐦 Traffic Management — 35 points

T1 (Hands-on · 10 pts · ~12 min). telemetry-api in namespace orbit has two live subsets, v1 and v2. You need a canary split with resilience built in.

Your task:

1. Write a DestinationRule defining subsets v1 and v2, with a trafficPolicy that circuit-breaks at 50 concurrent TCP connections and ejects an endpoint after 3 consecutive 5xx errors within a 10s window, for up to 30s, capped at half the pool.
2. Write a VirtualService splitting traffic 80/20 between v1 and v2, with a 2s timeout and 2 retries at a 300ms per-try timeout on 5xx and reset.

Done when: a loop of 50 curls from the ground-console pod to telemetry-api lands roughly 4-in-5 on v1 and 1-in-5 on v2, and istioctl analyze -n orbit reports no subset or routing errors.

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: telemetry-api
  namespace: orbit
spec:
  host: telemetry-api.orbit.svc.cluster.local
  subsets:
    - name: v1
      labels: { version: v1 }
    - name: v2
      labels: { version: v2 }
  trafficPolicy:
    connectionPool:
      tcp: { maxConnections: 50 }
    outlierDetection:
      consecutive5xxErrors: 3
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: telemetry-api
  namespace: orbit
spec:
  hosts: ["telemetry-api"]
  http:
    - timeout: 2s
      retries:
        attempts: 2
        perTryTimeout: 300ms
        retryOn: 5xx,reset
      route:
        - destination: { host: telemetry-api, subset: v1 }
          weight: 80
        - destination: { host: telemetry-api, subset: v2 }
          weight: 20

T2 (Hands-on · 8 pts · ~9 min). External callers need to reach telemetry-api through the mesh's ingress gateway at host telemetry.orbit.example.com over plain HTTP.

Your task:

1. Write a Gateway named orbit-gateway selecting the demo profile's ingress gateway workload, listening on port 80 for that host.
2. Write a VirtualService that binds to both the gateway and the mesh, and routes matching requests to telemetry-api.

Done when: a curl -H "Host: telemetry.orbit.example.com" against the ingress gateway's external address returns 200, and in-mesh calls to telemetry-api from inside the cluster keep working too.

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: orbit-gateway
  namespace: orbit
spec:
  selector:
    istio: ingressgateway
  servers:
    - port: { number: 80, name: http, protocol: HTTP }
      hosts: ["telemetry.orbit.example.com"]
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: telemetry-api-ingress
  namespace: orbit
spec:
  hosts: ["telemetry.orbit.example.com"]
  gateways: ["orbit-gateway", "mesh"]   # omit "mesh" and in-mesh callers lose this route
  http:
    - route:
        - destination: { host: telemetry-api }

T3 (Hands-on · 7 pts · ~8 min). The mesh is running with outboundTrafficPolicy.mode: REGISTRY_ONLY, so nothing not explicitly declared can leave it. telemetry-api needs to call an external service at api.weatherstation.example over HTTPS on port 443.

Your task: write the resource that registers this external host so calls to it are permitted.

Done when: a curl from telemetry-api's pod to https://api.weatherstation.example succeeds, while a curl to any other unlisted external host is still blocked by the registry-only policy.

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: weatherstation-api
  namespace: orbit
spec:
  hosts: ["api.weatherstation.example"]
  ports:
    - number: 443
      name: https
      protocol: TLS
  resolution: DNS
  location: MESH_EXTERNAL

T4 (🐦 Traffic Management · Multiple choice · 5 pts · ~3 min). A VirtualService's route references a subset named canary, but the DestinationRule for that host defines only v1 and v2 — no canary subset exists. What is the most likely observed behavior?

• A. The request is silently routed to v1 instead
• B. Requests fail — Envoy has no cluster configured for a subset that doesn't exist, typically surfacing as a 503
• C. The mTLS handshake fails
• D. The Gateway refuses to accept new listeners

T5 (🐦 Traffic Management · Multiple choice · 5 pts · ~3 min). Which of the following is not one of the five resilience features the ICA curriculum names under "Using Resilience Features"?

• A. Circuit breaking
• B. Outlier detection
• C. Rate limiting
• D. Timeouts and retries

🐢 Securing Workloads — 25 points

S1 (Hands-on · 10 pts · ~12 min). The orbit namespace needs zero-trust workload identity, and telemetry-api should accept reads only from one known caller.

Your task:

1. Write a PeerAuthentication that requires mTLS for every workload in orbit.
2. Write an AuthorizationPolicy that allows only the ground-console ServiceAccount to call GET /api/readings* on telemetry-api.

Done when: a GET /api/readings call from the ground-console pod succeeds, the identical call from the weather-sync pod returns RBAC: access denied, and a plaintext (non-mTLS) call to telemetry-api from outside the mesh is rejected outright.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: orbit
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-ground-console-reads
  namespace: orbit
spec:
  selector:
    matchLabels: { app: telemetry-api }
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/orbit/sa/ground-console"]
      to:
        - operation:
            methods: ["GET"]
            paths: ["/api/readings*"]

S2 (Hands-on · 6 pts · ~8 min). External callers should reach telemetry-api over HTTPS at the edge. A TLS secret named orbit-tls-cert already exists in the gateway's own namespace, istio-system.

Your task: write a Gateway that terminates TLS at the edge for host telemetry.orbit.example.com using that secret.

Done when: curl https://telemetry.orbit.example.com against the ingress gateway completes a TLS handshake and returns 200.

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: orbit-gateway-tls
  namespace: istio-system         # credentialName must sit in the gateway's own namespace
spec:
  selector:
    istio: ingressgateway
  servers:
    - port: { number: 443, name: https, protocol: HTTPS }
      hosts: ["telemetry.orbit.example.com"]
      tls:
        mode: SIMPLE
        credentialName: orbit-tls-cert

S3 (🐢 Securing Workloads · Multiple choice · 5 pts · ~3 min). A team needs to reject requests carrying an invalid JWT, but must let requests with no JWT at all pass through untouched. Which single resource, configured alone, achieves exactly this?

• A. RequestAuthentication alone
• B. PeerAuthentication in STRICT mode alone
• C. AuthorizationPolicy alone
• D. None of these alone — always pair two of them

S4 (🐢 Securing Workloads · Multiple choice · 4 pts · ~3 min). An AuthorizationPolicy rule is meant to require both a specific caller identity and a valid JWT. The author writes the identity check and the JWT check as two separate - source: entries under from instead of two keys inside one source: block. What's the practical effect?

• A. No effect — both forms are identical
• B. The policy now requires identity or valid token, not identity and valid token — a hole, not a policy
• C. The policy becomes stricter, requiring both twice
• D. The policy fails to apply at all and is silently ignored

🦫 Installation, Upgrades & Configuration — 20 points

I1 (Hands-on · 8 pts · ~9 min). Starting from a bare cluster with no mesh installed, bring up Istio and enroll the orbit namespace in sidecar mode.

Your task:

1. Install Istio using istioctl with the demo profile.
2. Label orbit for sidecar injection and restart any workloads already running there.

Done when: kubectl -n istio-system get pods shows istiod and both gateways Running, and every pod in orbit reads 2/2 containers ready.

istioctl install --set profile=demo -y
kubectl -n istio-system get pods                 # istiod, istio-ingressgateway, istio-egressgateway

kubectl label namespace orbit istio-injection=enabled
kubectl -n orbit rollout restart deployment       # injection only applies at pod creation
kubectl -n orbit get pods                         # every app pod should now read 2/2

I2 (Hands-on · 6 pts · ~9 min). A second Istio version needs to reach orbit without touching any other namespace, using a canary upgrade rather than an in-place one.

Your task:

1. Install a second control plane under revision 1-25-0.
2. Create a revision tag orbit-stable pointing at it.
3. Move only the orbit namespace onto the new revision and restart it.

Done when: istioctl proxy-status shows every proxy in orbit synced against the 1-25-0 control plane, while proxies in any other namespace remain on the original.

istioctl install --set revision=1-25-0 -y
istioctl tag set orbit-stable --revision 1-25-0

kubectl label namespace orbit istio-injection- --overwrite      # remove the plain label first
kubectl label namespace orbit istio.io/rev=1-25-0 --overwrite
kubectl -n orbit rollout restart deployment

istioctl proxy-status                              # orbit rows show revision 1-25-0, SYNCED

I3 (🦫 Installation · Multiple choice · 3 pts · ~2 min). Which label correctly enrolls a namespace in ambient mode, as distinct from sidecar mode?

• A. istio-injection=enabled
• B. istio.io/dataplane-mode=ambient
• C. istio.io/rev=ambient
• D. sidecar.istio.io/inject=false

I4 (🦫 Installation · Multiple choice · 3 pts · ~2 min). Installing Istio via Helm rather than istioctl, which order must the three charts be installed in?

• A. istiod, then base, then gateway
• B. gateway, then base, then istiod
• C. base, then istiod, then gateway
• D. Order doesn't matter — Helm resolves it automatically

🐘 Troubleshooting — 20 points

D1 (Hands-on · 8 pts · ~9 min). After a routing change, calls to telemetry-api started returning 503s. The DestinationRule from T1 is in place, but the VirtualService was just edited by a teammate.

Your task: using the mesh's own tooling — not a guess — find what the teammate broke, and fix it.

Done when: istioctl analyze -n orbit reports no errors, and curls to telemetry-api succeed again.

# 1. Configuration first — lint before assuming a network fault
istioctl analyze -n orbit
# analyze typically reports something like:
#   Warning [IST0101] VirtualService telemetry-api: subset "cannary"
#   referenced by route is not found in DestinationRule "telemetry-api"

# 2. Confirm at the data-plane layer, one proxy at a time
istioctl proxy-config route telemetry-api-7d9f-abcde.orbit --name 80

# 3. Fix the typo in the VirtualService's route and reapply
kubectl -n orbit edit virtualservice telemetry-api   # cannary -> v2
istioctl analyze -n orbit                            # clean

D2 (Hands-on · 6 pts · ~7 min). The weather-sync ServiceAccount reports RBAC: access denied calling telemetry-api, even though a teammate insists they wrote an AuthorizationPolicy that should allow it.

Your task: find the bug in the existing policy below and fix it — do not simply delete it.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-weather-sync
  namespace: orbit
spec:
  selector:
    matchLabels: { app: telemetry-api }
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/orbit/sa/weather_sync"]   # <- bug is in here
      to:
        - operation:
            methods: ["GET"]

Done when: GET calls from the weather-sync pod to telemetry-api succeed.

            principals: ["cluster.local/ns/orbit/sa/weather-sync"]

D3 (🐘 Troubleshooting · Multiple choice · 3 pts · ~2 min). Running istioctl proxy-status, one proxy's row reads STALE instead of SYNCED. What does that mean?

• A. The proxy has received no configuration at all yet
• B. The control plane has a newer configuration push that hasn't reached this proxy — it's running out-of-date config
• C. The workload has no sidecar injected
• D. The proxy's mTLS certificate has expired

D4 (🐘 Troubleshooting · Multiple choice · 3 pts · ~2 min). Immediately after enabling STRICT mTLS on a namespace, a handful of calls that used to work start failing. What is the single most likely cause?

• A. The DestinationRule was deleted
• B. Something outside the mesh is calling in directly — an unlabeled namespace, a liveness probe, or a client hitting a pod IP without a sidecar
• C. The Istio version was downgraded
• D. The ingress gateway's certificate expired

Score yourself

☺ Like you're 10: Add up your points, but then look at which of the four groups cost you the most — that second part is the useful part.

Mark after a break, not immediately — marking your own work while still adrenalised produces generous nonsense. For hands-on tasks, award full points only when the done-when check actually passed on your cluster, half when the resource exists and is broadly right but the check didn't pass, and zero for anything unattempted. Multiple-choice items are binary: full points for the correct letter, zero otherwise — there's no partial credit for a right idea and a wrong click. The Linux Foundation doesn't publish a pass mark for the ICA at all; treat a comfortable, round 75 of 100 as this course's own rough target, not a guaranteed line on the real exam, and verify current guidance on the official Linux Foundation ICA page before you rely on any number here.

Sort every miss into one of three piles, because each calls for a different fix. A hands-on task where you didn't know which resource to reach for is a genuine content gap — reread the matching section of the blueprint and redo the exact task cold in a couple of days. A hands-on task where you knew the shape but the YAML had a small, silent error — like D2's typo'd ServiceAccount name — is a precision problem, and the fix is more untimed reps in the practice bank, typing every manifest out in full rather than copying it. A multiple-choice miss where you genuinely didn't know the fact is the plainest kind of gap and the cheapest to close by rereading; a miss where you knew it and still picked wrong under time pressure is a confidence problem, and the fix is another timed paper, not more reading.

After the sitting

☺ Like you're 10: Practice only the parts you got wrong, and save the next two tests for when you're actually ready for them.

Resist the urge to re-drill everything. The whole value of a scored, weighted paper is that it tells you where not to spend your next week. Take your weakest domain and your weakest item type, work only those — the blueprint and the practice bank both split cleanly along the same four domains — and re-run the specific tasks you flagged rather than the whole paper. Everything else you already demonstrated under a clock; grinding it again is comfort, not preparation. Leave Set 2 and Set 3 genuinely sealed until then, spacing them a few days apart as your remaining cold measurements before the real exam.

That's the full sitting. Reset the timer, close every tab except whatever documentation you've actually verified is permitted, and let the seventeen items above show you exactly which of the four domains — and which item type — is still soft. Fix precisely that, and nothing else, before you move on to Set 2.