ICA Practice Tasks & Questions

The ICA is the odd one on this whole ladder: an online, remote-proctored sitting that mixes performance-based tasks at a real command line with multiple-choice items, in one two-hour block. Most study banks pick a lane — a pile of MCQs, or a pile of labs — and leave you to guess how the other half feels. This one doesn't. It holds six hands-on tasks (T1–T6), each with a worked solution and a command you actually run to prove it, and sixteen multiple-choice questions (Q1–Q16) with full option-by-option explanations — both split across the four official domains from the ICA blueprint in rough proportion to their weight. Work a domain's tasks cold and timed first, since that's the skill reading never builds; then work its questions. When both sets stop surprising you, move to the timed papers — Mock Exam · Set 1, Set 2 and Set 3.

How this bank is built

☺ Like you're 10: Two piles, not one — a pile of "actually do it" and a pile of "pick the right answer" — and both piles are biggest where the real exam is biggest.

The ICA's four domains — Traffic Management 35%, Securing Workloads 25%, Installation/Upgrades/Configuration 20%, Troubleshooting 20% — come straight from the CNCF's published curriculum; see the blueprint for the full competency list and exam logistics. This bank mirrors that shape twice over: two tasks and six questions on Traffic Management, two tasks and four questions on Securing Workloads, one task and three questions each on Installation and Troubleshooting. Neither the exact task-to-question ratio nor the total item count on the real paper is published anywhere — the split here is this bank's own design, built to give you real reps in both formats without either pile growing so large it stops being an untimed, readable drill.

Traffic Management — 35%

☺ Like you're 10: This is the biggest pile because it's the biggest slice of the real test — moving traffic around, splitting it, and making sure it survives when something breaks.

Seven named competencies live here: ingress and egress, in-mesh routing, DestinationRule traffic policy, traffic shifting, connecting to external services, resilience (circuit breaking, failover, outlier detection, timeouts, retries) and fault injection. Two resources carry almost all of it — VirtualService decides where a request goes, DestinationRule decides what happens once it gets there — and the tasks below deliberately make you write both, together, more than once.

T1 · Split traffic 90/10 with a canary override, and make the losing side resilient

The reviews service runs two versions behind one Kubernetes Service — v1 (stable) and v2 (canary), distinguished by the pod label version. Product wants 90% of ordinary traffic on v1 and 10% on v2, but any request carrying the header x-canary: always should go to v2 regardless of the split. Separately, v1 has been flaky under load and needs circuit breaking so one bad instance can't take the whole subset down with it.

Your task:

1. Write a DestinationRule for reviews defining subsets v1 and v2.
2. Add a trafficPolicy on the v1 subset: a connection pool capping HTTP requests, and outlier detection ejecting an endpoint after 5 consecutive 5xx responses.
3. Write a VirtualService that routes header-matched traffic to v2 first, then splits everything else 90/10.

Done when: curl -H "x-canary: always" always lands on v2; a loop of a hundred plain requests lands roughly 90 on v1 and 10 on v2; and istioctl proxy-config cluster <pod> --fqdn reviews.default.svc.cluster.local shows the outlier-detection settings attached to the v1 cluster.

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
  namespace: default
spec:
  host: reviews.default.svc.cluster.local
  subsets:
    - name: v1
      labels: { version: v1 }
      trafficPolicy:                 # ---- subset-level override: only v1 gets this ----
        connectionPool:
          http:
            http1MaxPendingRequests: 32
            maxRequestsPerConnection: 10
        outlierDetection:
          consecutive5xxErrors: 5
          interval: 10s
          baseEjectionTime: 30s
          maxEjectionPercent: 50
    - name: v2
      labels: { version: v2 }
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
  namespace: default
spec:
  hosts: ["reviews"]
  http:
    - match:                         # first match wins — the header rule MUST come before the split
        - headers:
            x-canary: { exact: "always" }
      route:
        - destination: { host: reviews, subset: v2 }
    - route:                         # fallback: everyone who didn't match above
        - destination: { host: reviews, subset: v1 }
          weight: 90
        - destination: { host: reviews, subset: v2 }
          weight: 10

for i in $(seq 1 100); do
  kubectl exec deploy/sleep -- curl -s -o /dev/null -w '%{http_code} ' \
    http://reviews.default.svc.cluster.local/api/v1/reviews
done
kubectl exec deploy/sleep -- curl -s -H 'x-canary: always' \
  http://reviews.default.svc.cluster.local/api/v1/reviews   # always v2
istioctl proxy-config cluster deploy/sleep --fqdn reviews.default.svc.cluster.local -o json

T2 · Expose one service to the internet, and lock every other outbound call down

The storefront app needs to (a) be reachable from outside the cluster at shop.example.com, and (b) be allowed to call exactly one external API, payments.example.net, and nothing else external — no accidental calls to a stray SaaS endpoint, no data exfiltration path via an unlisted host.

Your task:

1. Write a Gateway bound to the ingress gateway workload, listening on port 443 for host shop.example.com.
2. Write a VirtualService attaching that Gateway and routing to storefront.
3. Write a ServiceEntry for payments.example.net.
4. Set outboundTrafficPolicy.mode: REGISTRY_ONLY, scoped narrowly to the storefront namespace via a Sidecar resource rather than mesh-wide.

Done when: external traffic reaches storefront through the gateway; a call from a storefront pod to payments.example.net succeeds; a call from that same pod to any other external host (e.g. example.com) fails outright rather than silently passing through.

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: storefront-gw
  namespace: storefront
spec:
  selector:
    istio: ingressgateway           # matches the ingress gateway Deployment's pod labels
  servers:
    - port: { number: 443, name: https, protocol: HTTPS }
      hosts: ["shop.example.com"]
      tls: { mode: SIMPLE, credentialName: shop-example-com-tls }
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: storefront
  namespace: storefront
spec:
  hosts: ["shop.example.com"]
  gateways: ["storefront-gw"]        # omit this and the rule only applies in-mesh, never to the gateway
  http:
    - route:
        - destination: { host: storefront, port: { number: 8080 } }
---
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: payments-api
  namespace: storefront
spec:
  hosts: ["payments.example.net"]
  ports:
    - { number: 443, name: https, protocol: TLS }
  resolution: DNS
  location: MESH_EXTERNAL
---
apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: default
  namespace: storefront
spec:
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY               # anything not a known Service or ServiceEntry: blocked

kubectl -n storefront exec deploy/storefront -- curl -sS -m 5 https://payments.example.net/health   # OK
kubectl -n storefront exec deploy/storefront -- curl -sS -m 5 https://example.com                   # blocked

Traffic Management — multiple choice (Q1–Q6)

Q1. A VirtualService's route names destination.subset: canary. No DestinationRule for that host defines a subset called canary. What actually happens to a request matching that route?

• A. Istio silently falls back to routing across all pods, ignoring the subset name.
• B. The request fails — typically a 503 — because the named subset doesn't resolve to any cluster; istioctl analyze flags this as a configuration error.
• C. Kubernetes' API server rejects the VirtualService at kubectl apply time.
• D. The DestinationRule is auto-created with an empty subset matching zero pods.

Q2. A route under http[].route[] lists two destinations with weight: 60 and weight: 30. What is true of this configuration?

• A. Istio automatically normalizes the weights so they still sum to 100.
• B. The weights across all destinations in one route must sum to exactly 100; this route is invalid and istioctl analyze will flag it.
• C. Envoy interprets the two numbers as a 2:1 ratio regardless of their sum, so this behaves identically to 66/33.
• D. Only the first destination's weight is honored; the second is ignored.

Q3. Fault injection (fault.delay / fault.abort), request timeout, and retries with perTryTimeout are all configured on which single resource?

• A. DestinationRule
• B. Gateway
• C. VirtualService
• D. Sidecar

Q4. A Sidecar resource sets outboundTrafficPolicy.mode: REGISTRY_ONLY for a namespace, and a ServiceEntry exists for api.partner.com. What does this combination achieve?

• A. All outbound traffic from that namespace is automatically encrypted with mTLS, regardless of destination.
• B. Calls to any host not represented by a known Kubernetes Service or a ServiceEntry — such as an undeclared external API — are blocked, while calls to api.partner.com are allowed through.
• C. Istio automatically discovers and registers every external host the workload has ever called.
• D. Outbound calls are rate-limited to the QPS configured on the ServiceEntry.

Q5. Where does locality-aware failover (localityLbSetting) live, and what else must be configured for it to actually shift traffic?

• A. On the VirtualService, as a sibling of route; it requires no other configuration.
• B. On the DestinationRule's trafficPolicy, nested inside loadBalancer; it requires outlierDetection to be configured before it will shift anything.
• C. On the Gateway, as a top-level field; it requires a multi-cluster mesh to take effect.
• D. On the Sidecar resource; it requires outboundTrafficPolicy.mode: REGISTRY_ONLY.

Q6. An ingress VirtualService is written with no gateways field at all. What is the practical effect?

• A. It applies to every Gateway object in the same namespace automatically.
• B. It defaults to mesh, so it governs only in-mesh, sidecar-to-sidecar traffic — external requests arriving through any gateway ignore it entirely.
• C. kubectl apply rejects the object as incomplete.
• D. It applies to the default ingress gateway only, and no other.

Securing Workloads — 25%

☺ Like you're 10: Locks come in two kinds here — one checks whether you're wearing the right uniform, the other checks whether your ID badge is real — and a test question loves to mix them up on purpose.

Three competencies, and precision about which resource answers which question is most of what's tested. PeerAuthentication asks "must the caller present a mesh certificate?" — workload identity. RequestAuthentication asks "is this end-user's token valid?" — and on its own it only rejects invalid tokens, never absent ones. AuthorizationPolicy asks "is this specific caller allowed to do this specific thing?"

T3 · Ratchet a namespace to strict mTLS without breaking one legacy health check

The legacy namespace has been running with permissive mTLS while every workload was migrated onto the mesh. Migration is done, except one thing: an external load-balancer health probe, outside the mesh entirely, still calls legacy-api's /healthz on port 9000 in plain HTTP, and that call must keep working. Everything else in the namespace is now mesh-to-mesh and should require mTLS.

Your task:

1. Set the namespace-wide default PeerAuthentication for legacy to STRICT.
2. Add a workload-specific exception so legacy-api's port 9000 alone stays permissive, without weakening mTLS on any of its other ports.

Done when: a plaintext curl to legacy-api:9000/healthz from outside the mesh still returns 200; a plaintext call to any other port on legacy-api, or to any other workload in the namespace, is refused.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default                     # the reserved name for a namespace-wide policy
  namespace: legacy
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: legacy-api-health-exception
  namespace: legacy
spec:
  selector:                         # portLevelMtls is only valid on a selector-scoped policy
    matchLabels: { app: legacy-api }
  mtls:
    mode: STRICT
  portLevelMtls:
    9000:
      mode: PERMISSIVE               # health check on 9000 only; every other port stays STRICT

curl -sS -m 5 http://legacy-api.legacy.svc.cluster.local:9000/healthz    # 200, plaintext OK
curl -sS -m 5 http://legacy-api.legacy.svc.cluster.local:8080/api        # refused - STRICT applies

T4 · Require BOTH the right service identity and a valid token — not either one

The orders service should only accept calls that satisfy two conditions at once: the caller must be the web-frontend ServiceAccount, and the request must carry a JWT issued by https://accounts.example.com. A first draft of the policy technically applies both checks, but testing shows a request with a stolen, unrelated ServiceAccount token gets through as long as it carries any valid JWT — the AND was accidentally written as an OR.

Your task:

1. Write a RequestAuthentication for the issuer and its JWKS endpoint.
2. Write an AuthorizationPolicy that genuinely requires both the ServiceAccount identity and the JWT, correcting the AND/OR mistake.

Done when: a call from web-frontend's identity with a valid JWT succeeds; a call from any other identity with a valid JWT is denied; a call from web-frontend's identity with no JWT is denied.

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: orders-jwt
  namespace: prod
spec:
  selector:
    matchLabels: { app: orders }
  jwtRules:
    - issuer: "https://accounts.example.com"
      jwksUri: "https://accounts.example.com/.well-known/jwks.json"
---
# THE BROKEN FIRST DRAFT — two separate `- source:` entries ORs them together:
#   rules:
#     - from:
#         - source: { principals: ["cluster.local/ns/prod/sa/web-frontend"] }
#         - source: { requestPrincipals: ["https://accounts.example.com/*"] }
#   ...lets ANY valid-JWT caller through, identity check or not.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: orders-require-identity-and-jwt
  namespace: prod
spec:
  selector:
    matchLabels: { app: orders }
  action: ALLOW
  rules:
    - from:
        - source:                    # ONE source entry: both keys inside it are ANDed
            principals: ["cluster.local/ns/prod/sa/web-frontend"]
            requestPrincipals: ["https://accounts.example.com/*"]

Securing Workloads — multiple choice (Q7–Q10)

Q7. A workload has PeerAuthentication set to STRICT and no RequestAuthentication at all. A request arrives with no JWT. What happens?

• A. It's denied — STRICT mTLS alone also requires a valid JWT on every request.
• B. It's allowed through, as far as authentication goes — STRICT mTLS only enforces that the caller presents a valid mesh certificate; with no RequestAuthentication configured, nothing checks for a JWT at all.
• C. It's denied because AuthorizationPolicy always requires a JWT by default.
• D. The request hangs until a JWT is supplied, since Istio blocks on a missing token.

Q8. A namespace has one AuthorizationPolicy with action: ALLOW selecting the billing workload, permitting calls only from sa/reporting. A completely unrelated workload in the same namespace, notifications, has no AuthorizationPolicy selecting it at all. What can reach notifications?

• A. Nothing — once any AuthorizationPolicy exists anywhere in the namespace, every workload in that namespace becomes default-deny.
• B. Anything — notifications is unaffected, since default-deny is triggered only for a workload actually selected by an ALLOW policy, and this one selects only billing.
• C. Only sa/reporting, inheriting the same rule as billing.
• D. Nothing, because AuthorizationPolicy objects are cluster-scoped by default.

Q9. An AuthorizationPolicy's rules[0].from lists two separate entries: - source: { principals: [...] } and - source: { requestPrincipals: [...] }. What does this actually enforce?

• A. The caller must satisfy both the identity check and the token check — a strict AND.
• B. The caller must satisfy either the identity check or the token check — an OR, meaning a valid JWT alone is enough even from an unexpected identity.
• C. This is invalid YAML and the policy will fail to apply.
• D. Only the first entry is evaluated; the second is silently ignored.

Q10. A Gateway terminates TLS with tls.mode: SIMPLE and credentialName: shop-tls. In which namespace must the shop-tls Secret live for this to work with Istio's default SDS setup?

• A. Any namespace — credentialName is a cluster-wide reference.
• B. The same namespace as the Gateway object's own workload — typically the ingress gateway's namespace, such as istio-system.
• C. The namespace of the backend service the VirtualService ultimately routes to.
• D. The default namespace, always, regardless of where anything else is deployed.

Installation, Upgrades & Configuration — 20%

☺ Like you're 10: Two ways to build it, two ways to update it — and the test wants to know you didn't just memorize one path and hope the other never comes up.

Four competencies: installing with istioctl or Helm, installing in sidecar or ambient mode, customizing the installation, and upgrading canary or in-place. The task below drills the canary path specifically, because it's the one people skip in real life — most teams upgrade in place, under time pressure, and never get the reps a graded exam expects.

T5 · Run a canary control-plane upgrade and prove it landed, without touching anything untested

Production is running istiod at revision 1-26-0, referenced by every namespace via the plain istio-injection=enabled label. A new Istio version needs to reach one low-risk namespace, staging, first — fully verified — before anything else moves.

Your task:

1. Install a second control plane under revision 1-27-0, alongside the existing one.
2. Move only staging onto it, and restart its workloads.
3. Verify every proxy in staging is actually talking to the new control plane before calling it done.

Done when: istioctl proxy-status shows every proxy in staging reporting SYNCED against the 1-27-0 control plane, and every other namespace is untouched and still on 1-26-0.

# 1. Install the new revision alongside the old one - nothing moves yet
istioctl install --set revision=1-27-0 -y

# 2. staging currently has BOTH istio-injection=enabled (implicit, from the old default)
#    AND is about to get istio.io/rev - the plain label wins if both are present,
#    so remove it explicitly before adding the revision label.
kubectl label namespace staging istio-injection-
kubectl label namespace staging istio.io/rev=1-27-0

# 3. Injection only happens at pod creation - existing pods are never retrofitted
kubectl rollout restart deployment -n staging

# 4. Verify BEFORE calling it done - don't trust the label change alone
istioctl proxy-status | grep staging      # every row: SYNCED, istiod-1-27-0-...

# Only after staging is fully verified would a stable tag move a whole fleet:
istioctl tag set prod-stable --revision 1-27-0
kubectl label ns staging istio.io/rev- istio.io/tag=prod-stable --overwrite

Installation & Configuration — multiple choice (Q11–Q13)

Q11. Installing Istio via Helm uses three charts. What is the required order?

• A. istiod, then base, then gateway — the control plane must exist before its CRDs.
• B. base (CRDs and cluster roles), then istiod, then gateway per ingress or egress gateway.
• C. Order doesn't matter — Helm resolves any dependency ordering automatically across the three charts.
• D. gateway, then base, then istiod.

Q12. Which statement correctly distinguishes an in-place upgrade from a canary upgrade?

• A. In-place replaces the running control plane directly, all at once; canary installs a second istiod under a revision and moves namespaces onto it one at a time via a label, so rollback is just relabelling.
• B. Canary and in-place are two names for the same underlying mechanism, differing only in CLI flag.
• C. In-place requires a revision label on every namespace; canary does not.
• D. Canary can only be performed with Helm; in-place can only be performed with istioctl.

Q13. A namespace carries both the label istio-injection=enabled and the label istio.io/rev=1-27-0 at the same time. Which one actually governs sidecar injection for new pods?

• A. istio.io/rev always wins, since it's the more specific label.
• B. istio-injection=enabled wins; the revision label is ignored while the plain label is present.
• C. Both apply simultaneously, and the pod gets two sidecars.
• D. Neither applies — having both present disables injection entirely as a safety measure.

Troubleshooting — 20%

☺ Like you're 10: Something's broken and you have three places to look — did you write the config wrong, is the brain of the mesh confused, or does one specific messenger not know what you think it knows? Check them in that order.

Three named competencies, and they name a ladder: configuration, the control plane, the data plane. istioctl analyze catches most configuration mistakes before they cause a symptom. istioctl proxy-status tells you whether the control plane's version of the truth actually reached every proxy. istioctl proxy-config asks one specific proxy what it currently believes — which is sometimes different from what you'd expect even when the first two steps look clean.

T6 · A routing change causes 503s that analyze doesn't catch

Someone rolled out a new subset, v3, for the checkout service. The DestinationRule already defines a v3 subset, and the VirtualService already routes 20% of traffic to it. istioctl analyze reports no problems. Requests to v3 still fail with 503 UF, upstream connect error... NO_HEALTHY_UPSTREAM.

Your task: find the actual root cause and fix it — without touching the VirtualService or DestinationRule, both of which are already correct.

Done when: istioctl proxy-config endpoint for the v3 cluster lists at least one healthy endpoint, and a request routed to v3 returns 200.

# 1. CONFIGURATION rung - already clean, per the prompt, but confirm it yourself
istioctl analyze -n prod

# 2. CONTROL PLANE rung - is the config actually reaching proxies?
istioctl proxy-status | grep checkout          # SYNCED - so the control plane isn't the problem

# 3. DATA PLANE rung - what does the cluster actually resolve to?
istioctl proxy-config cluster checkout-7c9d-abcde.prod \
  --fqdn checkout.prod.svc.cluster.local --port 8080 -o json
#   -> finds a cluster named "outbound|8080|v3|checkout.prod.svc.cluster.local"

istioctl proxy-config endpoint checkout-7c9d-abcde.prod \
  --cluster "outbound|8080|v3|checkout.prod.svc.cluster.local"
#   -> ZERO endpoints listed. The cluster exists; nothing backs it.

# The actual cause: the DestinationRule's v3 subset selects { version: v3 },
# but the Deployment's pod template still carries { version: v3-rc1 }.
kubectl -n prod get pods -l app=checkout --show-labels
kubectl -n prod patch deployment checkout-v3 --type=json \
  -p '[{"op":"replace","path":"/spec/template/metadata/labels/version","value":"v3"}]'
kubectl -n prod rollout status deployment/checkout-v3

istioctl proxy-config endpoint checkout-7c9d-abcde.prod \
  --cluster "outbound|8080|v3|checkout.prod.svc.cluster.local"   # now lists healthy endpoints

Troubleshooting — multiple choice (Q14–Q16)

Q14. Put the three troubleshooting rungs in the order the curriculum names them, and match each to its primary command.

• A. Data plane (proxy-config) → Control plane (proxy-status) → Configuration (analyze).
• B. Configuration (analyze) → Control plane (proxy-status) → Data plane (proxy-config).
• C. Control plane (proxy-status) → Data plane (proxy-config) → Configuration (analyze).
• D. There is no defined order; any rung may be checked first with equal efficiency.

Q15. In istioctl proxy-status output, one proxy's row shows STALE in the CDS column, and another shows NOT SENT. What does each mean?

• A. Both mean the same thing — the proxy is out of date and needs a restart.
• B. STALE means istiod pushed an update but the proxy hasn't acknowledged consuming it yet; NOT SENT means istiod currently has nothing new to send that proxy at all.
• C. STALE means the proxy has crashed; NOT SENT means the proxy was never injected.
• D. STALE applies only to istiod itself; NOT SENT applies only to individual workloads.

Q16. A namespace is labelled istio-injection=enabled, but a pod that was already Running before the label was applied still shows no istio-proxy container. What is the most likely cause?

• A. The CNI plugin is misconfigured and is blocking sidecar attachment.
• B. Injection is evaluated only at pod creation time; a pod that existed before the label was added is never retrofitted, and needs a rollout restart.
• C. The Istio version on that node doesn't support automatic injection.
• D. The namespace label was applied to the wrong object — labels must go on the Deployment, not the namespace.

Running this bank like exam day

☺ Like you're 10: First time through, go slow and read everything. Once nothing here surprises you anymore, do it again with a clock running, because the real test has one.

Two passes, not one. On the first pass, work every task cold before opening its solution, and read every question's full explanation even when you got it right — the goal is coverage, not speed. On the second pass, once the material has settled, time yourself: five to ten minutes per task, roughly ninety seconds per question, and treat the whole bank as one 45–60 minute sitting with only istio.io open in another tab — because that's the one resource a real hands-on Linux Foundation exam typically allows, and finding the right page under pressure is its own exam skill.

Once every task and question here stops surprising you, move to the timed papers: Mock Exam · Set 1, Set 2 and Set 3. For the full domain breakdown and exam logistics, see the ICA blueprint; for a day-by-day route through all of it, see the ICA study plan. If a mesh is genuinely part of your platform work rather than just this badge, Platform Engineering's own ICA page places it inside the wider CNPE picture, and the Istio tool guide on this course covers the same resources at lesson pace rather than drill pace. Everything here assumes Kubernetes fluency the ICA itself doesn't teach — if Service, Deployment and label selectors aren't already second nature, a CKA-level foundation belongs before this bank, not after it.