ICA Mock Exam · Set 2

Twenty more items, split the way the real ICA is split — not fifty pure multiple-choice questions like the knowledge-only associates elsewhere on this shelf, but a mix of hands-on Task items, where you write the manifest or type the command yourself before checking a model solution, and ordinary MCQ items — weighted question-for-question to the same four official domains as the ICA curriculum: seven on Traffic Management, five on Securing Workloads, four on Installation, Upgrades & Configuration, four on Troubleshooting. This is the second of three papers on this shelf — see also Set 1 and Set 3 — and it assumes you already know the drill from a hybrid paper: a Task item wants typed, working YAML or a real istioctl command, not a description of one. None of these twenty repeat a scenario used elsewhere on this course. Answer each item in full before opening its model solution.

How this paper is weighted

☺ Like you're 10: Same shape as the real test — the biggest topic still gets the most questions, and every topic gets a mix of "build it" and "pick it."

Twenty items divide the ICA's four official domain weights — 35, 25, 20, 20 — into whole numbers with no rounding: 7, 5, 4, 4. That total is deliberately modest. The Linux Foundation doesn't publish an exact item count for the ICA — candidate write-ups cluster loosely around fifteen to twenty items across the two-hour sitting, and this paper's size was chosen to sit inside that same range rather than to claim a real number. Within each domain, most items lean Task where the real curriculum's own competencies read as verbs (configuring, installing, troubleshooting), and MCQ where a scenario tests understanding of a rule rather than the ability to type it.

Two item types, one exam

☺ Like you're 10: Some questions want you to pick an answer. Some want you to actually build the thing, from nothing, and show your work.

Every MCQ item below works like the ones you know from every other cert on this shelf: four options, one best answer, an explanation underneath. Every Task item works differently on purpose — it names a service, a namespace, and a concrete requirement, and it wants you to actually write the resource or type the command before you look. Resist the urge to read a Task stem and mentally nod "yes, I know roughly what goes there" without producing real YAML; that mental shortcut is exactly the gap a Task item exists to catch, and it's invisible until you're staring at a blank editor on exam day with a proctor watching the clock. Some Linux Foundation hands-on exams permit one browser tab of official documentation during the performance-based portion — the current candidate handbook is the only place to confirm whether that applies here, and if it does, practising with only that one tab open (not a full search engine) is itself part of the skill.

Sit it like the real thing

☺ Like you're 10: No notes, no open tabs beyond whatever the real exam actually allows, one sitting, straight through — and for the Task items, an actual terminal, not a guess written in your head.

Sit this with a real cluster in front of you — a local kind or minikube cluster with Istio installed is enough — so the nine Task items are graded by whether your YAML actually applies and does what the stem asked, not by whether it merely looks plausible. Time yourself against the pacing above: roughly 42 minutes of attention on Traffic Management items, 30 on Securing Workloads, 24 each on Installation/Upgrades and Troubleshooting, though in practice the Task items will eat more of your budget than the MCQ items do — expect that, and don't panic when it happens. This course does not re-teach the Kubernetes fluency the ICA assumes; if kubectl and Services still feel effortful, The Kubernetes Baseline You Need or the sibling Kubernetes course is the better use of today than this paper.

The paper — 20 items across four domains

☺ Like you're 10: Twenty questions, grouped by topic this time instead of shuffled — build something, then pick an answer, back and forth, all the way through.

Each item names its domain and type in parentheses. Task items give a scenario and a concrete requirement; open the model solution only after you've written your own version. MCQ items give four options and a worked explanation.

Block 1 — Traffic Management (Q1–Q7)

Q1 (Traffic Management, Task). The life-support service in namespace hab has two subsets, v1 and v2. Write a DestinationRule that caps the connection pool at 50 TCP connections, and configures outlier detection to eject an endpoint after 3 consecutive 5xx errors, with a 15-second base ejection time and a maximum ejection of 40% of the pool.

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: life-support
  namespace: hab
spec:
  host: life-support.hab.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: 15s
      maxEjectionPercent: 40

Q2 (Traffic Management, MCQ). A VirtualService for docking-api routes 60% of traffic to subset v1 and 30% to subset v2, with no third route entry accounting for the remaining 10%. What does the curriculum's traffic-shifting competency say is wrong here?

• A. Nothing — the unaccounted 10% is automatically folded into v1 by default
• B. Route weights within one route block must sum to 100; the missing 10% is unaccounted for and should be given an explicit destination rather than left implicit
• C. Nothing — traffic shifting only ever supports two subsets at a time, so 60/30 is treated as 100
• D. This is only a problem if v1 and v2 are on different clusters

Q3 (Traffic Management, Task). Write a VirtualService for comms-relay that routes any request carrying the exact header x-canary: true to subset canary, and for everything else applies fault injection — a 2% chance of a 500ms delay and a separate 2% chance of a 503 abort — plus a 3-second timeout and 2 retries at 1 second per try, retrying on 5xx and reset.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: comms-relay
  namespace: hab
spec:
  hosts: ["comms-relay"]
  http:
    - match:
        - headers:
            x-canary: { exact: "true" }
      route:
        - destination: { host: comms-relay, subset: canary }
    - fault:
        delay: { percentage: { value: 2 }, fixedDelay: 500ms }
        abort: { percentage: { value: 2 }, httpStatus: 503 }
      timeout: 3s
      retries:
        attempts: 2
        perTryTimeout: 1s
        retryOn: 5xx,reset
      route:
        - destination: { host: comms-relay, subset: v1 }

Q4 (Traffic Management, MCQ). An engineer wants exactly two external APIs reachable from the mesh, with everything else blocked by default. Which combination achieves this?

• A. A Kubernetes NetworkPolicy alone
• B. Two ServiceEntry resources declaring the two allowed external hosts, plus outboundTrafficPolicy.mode: REGISTRY_ONLY set in MeshConfig or on a Sidecar resource
• C. A single AuthorizationPolicy with an ALLOW action
• D. PeerAuthentication with mode: STRICT

Q5 (Traffic Management, Task). Write a VirtualService for nav-computer that shifts 80% of traffic to subset v1 and 20% to subset v2, with a 2-second timeout and 3 retries at 500ms per try, retrying on 5xx, reset, and connect-failure.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: nav-computer
  namespace: hab
spec:
  hosts: ["nav-computer"]
  http:
    - timeout: 2s
      retries:
        attempts: 3
        perTryTimeout: 500ms
        retryOn: 5xx,reset,connect-failure
      route:
        - destination: { host: nav-computer, subset: v1 }
          weight: 80
        - destination: { host: nav-computer, subset: v2 }
          weight: 20

Q6 (Traffic Management, MCQ). Which pairing correctly places each of the curriculum's five named resilience features on the resource that actually configures it?

• A. Timeouts and retries on the DestinationRule; circuit breaking and outlier detection on the VirtualService
• B. Timeouts, retries, and fault injection on the VirtualService; circuit breaking (via connectionPool) and outlier detection on the DestinationRule's trafficPolicy; failover also on the DestinationRule, via localityLbSetting
• C. All five live on the VirtualService; the DestinationRule only defines subsets
• D. All five live on the DestinationRule; the VirtualService only matches and routes

Q7 (Traffic Management, MCQ). A Gateway named beacon-gateway is deployed and listening, but a VirtualService written to route through it never receives any external traffic — only in-mesh calls reach it. What is the most likely cause?

• A. The VirtualService's gateways field is missing or omitted, so it defaults to mesh and applies only to in-mesh traffic, never to the named Gateway
• B. Gateway resources cannot be referenced by name, only by label selector
• C. The hosts field was set, which is only valid for in-mesh traffic
• D. External traffic requires a separate CNCF project entirely; Istio Gateways cannot serve ingress

Block 2 — Securing Workloads (Q8–Q12)

Q8 (Securing Workloads, Task). Write a PeerAuthentication that sets strict mTLS mesh-wide for namespace hab, and an AuthorizationPolicy that allows only the ServiceAccount flight-console to call GET and POST on paths under /api/o2-levels against the life-support app.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: hab
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-flight-console
  namespace: hab
spec:
  selector:
    matchLabels: { app: life-support }
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/hab/sa/flight-console"]
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/o2-levels*"]

Q9 (Securing Workloads, MCQ). Namespace hab has PeerAuthentication set to PERMISSIVE and a RequestAuthentication requiring a valid JWT from a specific issuer — but no AuthorizationPolicy at all. A request arrives with no JWT attached whatsoever. What happens?

• A. Rejected — RequestAuthentication requires every request to carry a token
• B. Allowed — RequestAuthentication only validates tokens that are actually present; it rejects an invalid token but never rejects a missing one on its own. Requiring a token to be present at all needs an AuthorizationPolicy rule on requestPrincipals
• C. Rejected — PERMISSIVE mode blocks any request not using mTLS
• D. Allowed only if the caller happens to be in the same namespace

Q10 (Securing Workloads, Task). Using nothing but a single AuthorizationPolicy with an empty spec, write a policy that leaves namespace hab with zero permitted callers for any workload it selects.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: hab
spec:
  {}                    # action defaults to ALLOW, with zero rules
                         # => nothing at all is permitted

Q11 (Securing Workloads, MCQ). A team wants an AuthorizationPolicy rule that requires a caller to hold both the ServiceAccount identity frontend and a valid JWT — not either one alone. They write two separate - source: entries under from, one with principals and one with requestPrincipals. What did they actually build?

• A. Exactly what they intended — identity AND a valid token, both required
• B. A rule that allows a caller with either the right identity or a valid token — not both — because separate list entries under from are ORed, while only keys inside the same source block are ANDed
• C. A syntax error; two - source: entries under one rule are not permitted
• D. A rule that is silently ignored, since AuthorizationPolicy only supports one condition per rule

Q12 (Securing Workloads, MCQ). A Gateway resource deployed in namespace istio-ingress references tls.credentialName: beacon-tls, but the matching Kubernetes Secret was created in namespace hab instead. What's the most likely result?

• A. The gateway still finds the Secret automatically, since credential lookups span the whole cluster by default
• B. TLS termination fails to find the credential — a Gateway's credentialName looks for the Secret in the gateway's own namespace, so it needs to be created in istio-ingress, not hab
• C. This only matters for mode: MUTUAL, never for mode: SIMPLE
• D. Nothing breaks; credentialName only affects mTLS between sidecars, not edge TLS

Block 3 — Installation, Upgrades & Configuration (Q13–Q16)

Q13 (Installation, Task). Using Helm rather than istioctl, write the full command sequence to install Istio for the first time onto a fresh cluster: the CRDs and cluster roles, the control plane, and one ingress gateway named beacon-gateway in namespace istio-ingress.

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 beacon-gateway istio/gateway -n istio-ingress --create-namespace

Q14 (Installation, MCQ). A team wants to enrol namespace cargo-bay in ambient mode, with no pod restarts or pod-spec changes required. Which single label achieves this?

• A. istio-injection=enabled — this is the standard sidecar-mode label
• B. istio.io/dataplane-mode=ambient — this enrols the namespace's workloads with the per-node ztunnel instead of injecting a sidecar into each pod
• C. istio.io/rev=default — this pins a namespace to the default sidecar revision
• D. No label is needed; ambient mode applies automatically once the cni chart is installed

Q15 (Installation, Task). Perform a canary upgrade of the control plane to revision 1-28-0, create a stable tag pointing at it, and then move exactly one namespace, hab, onto that revision.

istioctl install --set revision=1-28-0 -y            # second, parallel control plane
istioctl tag set hab-stable --revision 1-28-0        # stable alias for later moves
kubectl label ns hab istio.io/rev=1-28-0 --overwrite # move ONE namespace
kubectl rollout restart deployment -n hab            # sidecars must be recreated

Q16 (Installation, MCQ). A namespace already running pods is relabeled with istio-injection=enabled for the first time. After the label is applied, the existing pods still show no sidecar container. What single action fixes this?

• A. Nothing more is needed; the sidecar injects into running pods automatically within a few minutes
• B. kubectl rollout restart deployment — injection happens only at pod creation, so existing pods must be recreated to pick up the sidecar
• C. Delete and recreate the namespace itself
• D. Re-run istioctl install a second time

Block 4 — Troubleshooting (Q17–Q20)

Q17 (Troubleshooting, Task). Immediately after a traffic-shifting change to docking-api in namespace hab, clients start receiving 503 responses with NO_HEALTHY_UPSTREAM. Write the three-step diagnostic sequence, in order, and name the single most likely root cause.

# 1. CONFIGURATION — lint before blaming anything else
istioctl analyze -n hab

# 2. CONTROL PLANE — did the config actually reach every proxy?
istioctl proxy-status

# 3. DATA PLANE — what does one proxy actually believe?
istioctl proxy-config cluster  docking-api-7d9f-abcde.hab
istioctl proxy-config endpoint docking-api-7d9f-abcde.hab \
  --cluster "outbound|8080|v2|docking-api.hab.svc.cluster.local"

Q18 (Troubleshooting, MCQ). An application team reports their calls to life-support now fail with RBAC: access denied. Which layer is almost certainly responsible?

• A. A DNS misconfiguration
• B. An AuthorizationPolicy — this specific error string is Istio's authorization layer speaking, not a network-level failure
• C. A NetworkPolicy at the Kubernetes CNI layer
• D. An expired TLS certificate on the ingress gateway

Q19 (Troubleshooting, Task). Right after namespace hab is flipped to PeerAuthentication mode: STRICT, one deployment's liveness probe starts failing, even though the application itself is healthy. Name the most likely cause and the fix.

kubectl get pod <pod> -n hab -o yaml | grep rewriteAppHTTPProbers
istioctl proxy-config secret <pod>.hab   # confirm the workload cert actually arrived

Q20 (Troubleshooting, MCQ). Running istioctl proxy-status, one proxy shows STALE in its CDS column while every other proxy shows SYNCED. What does STALE mean here, as distinct from NOT SENT?

• A. STALE means istiod has nothing new to push to that proxy; NOT SENT means a push is stuck in flight
• B. STALE means a config push to that specific proxy is stuck and hasn't been acknowledged; NOT SENT means istiod has nothing queued to send it at all — different failure, different fix
• C. The two terms are interchangeable and both indicate the proxy has crashed
• D. STALE only ever appears immediately after a fresh install and can be ignored

Score yourself

☺ Like you're 10: Count what you got right out of twenty, then look at whether it was the "build it" half or the "pick it" half that cost you the most points.

Unlike the pure multiple-choice associates on this shelf, the Linux Foundation does not publish a confirmed pass mark for the ICA — there is no Multiple Choice Exam FAQ figure to calibrate against here, because the ICA isn't a pure multiple-choice exam. Treat 80% or better across both papers as a target to clear comfortably, not a confirmed cut score.

If you sat Set 1 first, compare domain breakdowns side by side. A domain still weak on both papers is real, not noise — reread it properly before you book anything. When you're ready to confirm that reading translated into typing speed, Set 3 is the third paper on this shelf.

Where each domain is taught

☺ Like you're 10: Every question above traces back to one of a handful of pages — go back to the page, not to the wider internet.

Nothing in this paper examines anything outside this course's own material. The ICA blueprint is the primary source for all four domains; where a topic needs the wider mesh-architecture picture, it lives in this course's own deep-dive material.

Beyond the domain pages, the wider revision kit still applies: the glossary for any term a stem assumed you already knew, flashcards for the vocabulary, and the ICA study plan for how to sequence all three papers against your remaining prep time. The Lock Down a Mesh Namespace drill is the closest thing on this course to a fourth Task item, run on your own cluster with no answer key waiting underneath it.