ICA Mock Exam · Set 3

This is the third and final timed paper in the ICA's three-set trio — thirty items covering the same four official domains as the ICA blueprint, but deliberately not shared out in the real exam's 35/25/20/20 proportions. Where Set 1 and Set 2 built even coverage across all four domains, Set 3 spends most of its budget on the two places real mesh incidents actually live: Troubleshooting, which carries eleven of these thirty items rather than its official fifth, and Securing Workloads, which carries nine. Because the real ICA is hybrid — hands-on tasks at a command line alongside multiple-choice items — most items here are written as diagnostic reading exercises: a manifest, a command's output, or a symptom, and four candidate fixes. Recognizing the right answer on a screen and typing it correctly under a proctor's eye are different skills; this paper drills the first and points you to the labs for the second.

How this paper is weighted, and why it leans where it leans

☺ Like you're 10: The real test gives routing the biggest slice. This practice paper gives troubleshooting and security the biggest slice instead, on purpose, because that's where the previous two papers left the most room to grow.

The ICA's four official domain weights — Traffic Management 35%, Securing Workloads 25%, Installation/Upgrades/Configuration 20%, Troubleshooting 20% — come straight from the CNCF's published curriculum and are covered in full, with the reasoning behind every field, on the ICA blueprint. This paper's thirty items do not mirror that split. They lean hard into the two domains where reading a scenario correctly matters more than reciting a definition:

Sit it like the real, hybrid thing

☺ Like you're 10: The real test has a typing half and a multiple-choice half. A page like this one can only give you the multiple-choice half — so treat every "which command" question here as a reminder to go type that exact command for real, not as the finish line.

Close every other tab and sit these thirty items in one block, the way you would the real paper's multiple-choice component. But be honest about what this format can and can't rehearse: the ICA is delivered online and remote-proctored as performance-based tasks at a real command line, plus multiple-choice items — no static page can simulate the first half. What it can do is train the diagnostic reading this exam actually rewards: given a manifest, a command's output, or a one-line symptom, choose the correct next action. That skill transfers directly to the hands-on half, because the real exam's tasks begin exactly the same way — something is broken or unconfigured, and you have limited time to name why before you start typing.

The paper — 30 items across three blocks

☺ Like you're 10: Thirty questions, three blocks of ten, every domain still shows up in every block — read the question, pick one answer (or two, when it says so), then check yourself before moving on.

Each item names its domain in parentheses so you can total your score by domain afterward. A few are marked (Select TWO); full credit needs both correct letters.

Block 1 — Q1–10

Q1 (Traffic Management). A team wants to let workloads inside the mesh call api.partner-service.com, an endpoint outside the cluster, while continuing to block every other undeclared external host. Which resource, paired with which setting, achieves this?

• A. A Gateway with tls.mode: MUTUAL
• B. A ServiceEntry for the external host, with outboundTrafficPolicy.mode: REGISTRY_ONLY set for the mesh
• C. A DestinationRule with an empty trafficPolicy
• D. A VirtualService with no hosts field at all

Q2 (Traffic Management). A VirtualService defines routing rules for host: checkout but its spec has no gateways field at all. What is the practical effect of that omission?

• A. The rules apply to both in-mesh and ingress traffic identically
• B. The rules apply only to in-mesh (east-west) traffic; requests arriving through an ingress Gateway never match them
• C. Istio rejects the VirtualService outright as invalid
• D. The rules apply only to ingress traffic and never to in-mesh calls

Q3 (Securing Workloads). Which PeerAuthentication mtls.mode accepts both plaintext and mutual-TLS connections at once, making it the standard setting for migrating a namespace toward zero trust without an outage?

• A. STRICT
• B. DISABLE
• C. PERMISSIVE
• D. UNSET

Q4 (Securing Workloads). A RequestAuthentication is applied to a workload with a correctly configured jwtRules issuer. A request arrives with no Authorization header at all — no token present. What happens?

• A. The request is rejected, because RequestAuthentication alone requires a token on every request
• B. The request is allowed through unauthenticated by RequestAuthentication alone — it only rejects invalid tokens, never missing ones; requiring a token needs a separate AuthorizationPolicy matching on requestPrincipals
• C. The request is silently converted to use PeerAuthentication instead
• D. Istio returns a 500 error because no AuthorizationPolicy exists

Q5 (Securing Workloads). In what order does Istio evaluate AuthorizationPolicy action types against an incoming request?

• A. ALLOW → DENY → CUSTOM
• B. DENY → ALLOW → CUSTOM
• C. CUSTOM → DENY → ALLOW
• D. All three are evaluated simultaneously with no defined order

Q6 (Installation, Upgrades & Configuration). Installing Istio via Helm, which order of chart installation is correct?

• A. istiod, then base, then gateway
• B. gateway, then base, then istiod
• C. base (CRDs and cluster roles), then istiod (control plane), then gateway per ingress/egress gateway
• D. Order doesn't matter — Helm resolves chart dependencies automatically for Istio

Q7 (Installation, Upgrades & Configuration). A namespace is freshly labeled istio-injection=enabled. Pods that were already running in that namespace before the label was applied — what happens to them?

• A. They are automatically restarted with a sidecar injected
• B. Nothing — injection happens only at pod creation time, so existing pods are never retrofitted; they need an explicit restart (e.g. kubectl rollout restart) to pick up the sidecar
• C. They immediately gain a sidecar without any restart, because the mutating webhook patches running pods live
• D. The namespace label has no effect on sidecar injection at all

Q8 (Troubleshooting). Before applying a new set of Istio manifests, or right after a change starts misbehaving, which single command should almost always run first?

• A. istioctl proxy-config route
• B. kubectl delete namespace and reapply everything from scratch
• C. istioctl analyze — a linter that catches missing subsets, conflicting policies, and unreferenced gateways before they surface as runtime errors
• D. istioctl x describe pod

Q9 (Troubleshooting). Reading this istioctl proxy-status output, what does the STALE value in the CDS column for one proxy most directly indicate?

NAME                                 CDS        LDS        EDS        RDS        ISTIOD
checkout-7d9f-abcde.launch           STALE      SYNCED     SYNCED     SYNCED     istiod-6b8f9-xk2p1
frontend-5c7a-mnop9.launch           SYNCED     SYNCED     SYNCED     SYNCED     istiod-6b8f9-xk2p1

• A. The proxy has no configuration at all and is completely unmanaged
• B. A configuration push to that proxy's cluster (CDS) data is stuck and hasn't been acknowledged — istiod sent it, but the proxy hasn't confirmed applying it
• C. The proxy's certificate has expired
• D. STALE is a healthy, expected steady-state value and needs no action

Q10 (Troubleshooting). A request that should be permitted returns RBAC: access denied. What kind of misconfiguration does that specific error text point to?

• A. A DNS resolution failure
• B. A missing DestinationRule subset
• C. An AuthorizationPolicy problem — this is a policy decision, not a network fault, so the fix starts by reading policies selecting that workload, not by checking connectivity
• D. An expired TLS certificate on the ingress Gateway

Block 2 — Q11–20

Q11 (Traffic Management). Given this pair, what happens once it is applied?

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: checkout
  namespace: launch
spec:
  host: checkout.launch.svc.cluster.local
  subsets:
    - name: v1
      labels: { version: v1 }
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: checkout
  namespace: launch
spec:
  hosts: ["checkout"]
  http:
    - route:
        - destination: { host: checkout, subset: v1 }
          weight: 90
        - destination: { host: checkout, subset: v2 }
          weight: 10

• A. Traffic silently routes 100% to v1 and the v2 weight is ignored
• B. The VirtualService references a v2 subset that the DestinationRule never defines — istioctl analyze should flag this before it's applied, and if applied anyway it produces errors for the 10% of traffic routed toward the undefined subset
• C. Istio automatically creates the missing v2 subset from the label selector
• D. The whole VirtualService is rejected at apply time by the API server

Q12 (Traffic Management). A VirtualService route sets timeout: 2s and retries: { attempts: 3, perTryTimeout: 1s }. What is the maximum time before the calling client receives a definitive response?

• A. Up to 3 seconds — three attempts at 1s each
• B. Up to 2 seconds — the overall route timeout bounds the entire request, including all retry attempts within it, and wins even if retries haven't been exhausted
• C. Unbounded — retries continue until one succeeds, no matter how long that takes
• D. Exactly 1 second, because perTryTimeout always overrides the route-level timeout

Q13 (Securing Workloads, Select TWO). This AuthorizationPolicy is meant to require that a caller be both the frontend service account and present a valid JWT. What is actually wrong with it, and what is the consequence? Choose the two correct statements.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-identity-and-jwt
  namespace: launch
spec:
  selector:
    matchLabels: { app: checkout }
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/launch/sa/frontend"]
        - source:
            requestPrincipals: ["https://accounts.example.com/*"]
      to:
        - operation: { methods: ["GET", "POST"] }

• A. Splitting the identity check and the JWT check into two separate - source: list entries makes them ORed, not ANDed — either condition alone now satisfies the rule
• B. This silently turns "identity and valid token" into "identity or valid token" — a caller with the right service-account identity and no token at all is allowed straight through
• C. This YAML is invalid and Istio rejects it at apply time
• D. Keys inside a single source block are always ORed regardless of how they're written
• E. This policy correctly enforces both conditions as written

Q14 (Securing Workloads). An AuthorizationPolicy is applied with an entirely empty spec: {} and a selector matching a workload. What is the effect on that workload?

• A. Nothing changes — an empty spec is a no-op
• B. action defaults to ALLOW with zero rules, meaning nothing at all is permitted to reach that workload — this locks it down completely
• C. All traffic is permitted by default, since no DENY rules are present
• D. Only traffic from outside the mesh is blocked; in-mesh calls proceed normally

Q15 (Securing Workloads). A workload has never had any AuthorizationPolicy select it, so all traffic reaches it freely. An operator then applies one narrowly scoped ALLOW policy permitting only GET requests from one service account. What happens to every other kind of request that used to work?

• A. Nothing — the new policy only adds a permission, it can't remove one that already existed
• B. The moment any ALLOW policy selects a workload, that workload becomes default-deny for everything not explicitly matched — so every request outside that one narrow rule is now rejected, even ones that worked a moment ago
• C. Old traffic patterns are grandfathered in for 24 hours before enforcement begins
• D. The workload reverts automatically to PERMISSIVE mode

Q16 (Installation, Upgrades & Configuration). What two components does enrolling a namespace in Istio's ambient mode rely on, in place of the per-pod sidecar used in sidecar mode?

• A. A second istiod revision and a canary tag
• B. A per-node ztunnel agent plus the cni chart, which redirects workload traffic to it — set via the istio.io/dataplane-mode=ambient namespace label rather than istio-injection=enabled
• C. A dedicated ingress Gateway per namespace
• D. A separate PeerAuthentication resource unique to ambient mode

Q17 (Installation, Upgrades & Configuration). A namespace carries both labels shown below at the same time. Which sidecar-injection behavior actually applies?

kubectl label namespace launch istio-injection=enabled
kubectl label namespace launch istio.io/rev=1-27-0

• A. Istio rejects both labels and injection is disabled entirely
• B. The plain istio-injection=enabled label wins, so pods are injected with the default revision — not the 1-27-0 revision the second label names
• C. The istio.io/rev label always wins over the plain label, so pods get revision 1-27-0
• D. Pods get two sidecars injected, one per matching label

Q18 (Troubleshooting). A client sees this after a routing change:

$ curl -v http://checkout.launch.svc.cluster.local/cart
< HTTP/1.1 503 Service Unavailable
< x-envoy-response-flags: UH
* Connection closed

What does the UH response flag most precisely indicate, and what's the likeliest cause right after a routing change?

• A. "Upstream Health" — the client's own network is unhealthy
• B. "No Healthy Upstream" — the target cluster exists but currently has zero healthy endpoints behind it, commonly because a VirtualService now routes to a subset a DestinationRule doesn't define, or every real endpoint has been ejected by outlier detection
• C. An expired mTLS certificate specifically
• D. A DNS failure resolving the service name

Q19 (Troubleshooting). A pod is running in a namespace labeled for sidecar injection, but kubectl describe pod shows only one container — no istio-proxy sidecar at all. What's the most likely explanation?

• A. The workload's Deployment explicitly opts out of the mesh
• B. Sidecar injection isn't supported for that workload's image
• C. The namespace label was applied after this pod was already running, and injection only ever happens at pod creation — it needs a restart to be re-created with the sidecar
• D. The istiod control plane is down

Q20 (Troubleshooting). You need to know exactly which routes are configured on port 8080 for one specific running proxy. Which command answers that, for that one proxy?

• A. istioctl analyze -n launch
• B. istioctl proxy-config route checkout-7d9f-abcde.launch --name 8080
• C. kubectl -n istio-system get pods
• D. istioctl profile diff default demo

Block 3 — Q21–30

Q21 (Traffic Management). On a DestinationRule's trafficPolicy, which setting implements circuit breaking, and which implements outlier detection, as two distinct mechanisms?

• A. Both are the same field under two different names
• B. connectionPool caps concurrent connections and requests per host — circuit breaking; outlierDetection watches for consecutive errors and ejects individual unhealthy endpoints from the load-balancing pool — two separate, complementary protections
• C. connectionPool handles ejection; outlierDetection handles connection limits
• D. Neither belongs on a DestinationRule; both live on the VirtualService

Q22 (Securing Workloads). To terminate TLS at an ingress Gateway, which two things does the Gateway resource need, and where must the referenced object live?

• A. A tls.mode of SIMPLE or MUTUAL, plus a credentialName naming a Secret — and that Secret must live in the Gateway's own namespace
• B. Only a credentialName; tls.mode is optional and defaults to MUTUAL
• C. A PeerAuthentication resource is required instead of any field on the Gateway itself
• D. The Secret can live in any namespace, referenced by full path

Q23 (Securing Workloads). A platform team is about to tighten a busy namespace's AuthorizationPolicy from wide-open to a narrow ALLOW list. What's the safest rollout order for the action field, from least to most disruptive?

• A. Go straight to DENY for anything unmatched — fastest is safest
• B. AUDIT first — logging what would be denied without actually blocking it — then move to DENY/tightened ALLOW once the audit log shows no legitimate caller would be cut off
• C. Rollout order doesn't matter; AuthorizationPolicy changes are always non-disruptive
• D. Apply ALLOW and DENY versions simultaneously and let Istio pick the safer one

Q24 (Securing Workloads). Mesh-wide istio-system sets PeerAuthentication to STRICT with no selector. A second PeerAuthentication in namespace launch sets PERMISSIVE for one specific port via portLevelMtls. For requests to that one port, in that namespace, which setting actually applies?

• A. The mesh-wide STRICT setting always wins over any namespace-level override
• B. The more specific, narrower-scoped policy wins — a namespace-level policy overrides the mesh-wide default, and a port-level override within it takes precedence for that port specifically
• C. Both apply simultaneously, requiring the request to satisfy both
• D. Port-level mtls settings are not a real feature — only namespace and mesh-wide scopes exist

Q25 (Installation, Upgrades & Configuration). Comparing an in-place upgrade to a canary upgrade, which correctly separates them?

• A. In-place installs a second istiod under a revision; canary replaces the running control plane directly, all at once
• B. In-place replaces the running control plane directly in one step, all-or-nothing; canary installs a second istiod under a named revision and moves namespaces onto it one at a time via the istio.io/rev label plus a restart
• C. Both strategies are functionally identical; "canary" is just marketing language for the same mechanism
• D. Canary upgrades never require restarting any workloads

Q26 (Troubleshooting). After confirming a workload's proxy is correctly configured and routes are correct, requests are still failing with mTLS handshake errors. Which command specifically checks whether the workload's certificate actually arrived at its proxy?

• A. istioctl proxy-config route
• B. istioctl proxy-config secret <pod>
• C. istioctl analyze
• D. istioctl profile diff

Q27 (Troubleshooting). Immediately after a canary upgrade moves half a fleet's namespaces to a new istiod revision, which command tells you which individual proxies are still connected to the old control plane revision?

• A. istioctl proxy-status — its output lists which istiod instance (and therefore which revision) each proxy is currently synced to
• B. istioctl x precheck
• C. kubectl get namespaces --show-labels
• D. There is no way to determine this per-proxy; you can only check per-namespace labels

Q28 (Troubleshooting). Immediately after a namespace is flipped from PERMISSIVE to STRICT mTLS, a wave of new connection failures begins. What's the most likely cause, and where should you look first?

• A. The istiod control plane has crashed
• B. Something calling into that namespace from outside the mesh's mTLS guarantee — an unlabeled namespace, a liveness probe hitting the pod directly, or a client calling a pod IP rather than the mesh-aware Service — since STRICT now rejects any connection that can't present a mesh certificate
• C. A DNS misconfiguration unrelated to the mTLS change
• D. STRICT mode never causes new failures if the mesh was already healthy under PERMISSIVE

Q29 (Troubleshooting). A teammate wants a single, readable summary of one pod's effective mTLS mode, the policies selecting it, and its routes, without manually cross-referencing several separate proxy-config subcommands. Which command is built for exactly that?

• A. istioctl proxy-config cluster
• B. istioctl x describe pod <pod> — a plain-English summary purpose-built to answer "what does the mesh currently believe about this one pod," pulling from policy, mTLS, and routing state together
• C. istioctl install --dry-run
• D. kubectl describe pod alone, with no istioctl involvement

Q30 (Troubleshooting, Select TWO). A specific call from frontend to checkout is being denied and you already suspect an AuthorizationPolicy is the cause, but you need to see exactly which rule fired and why. Which TWO actions get you there fastest?

• A. Turn up Envoy's own logging on the target proxy — istioctl proxy-config log checkout-7d9f-abcde.launch --level rbac:debug — then read the resulting istio-proxy container logs for the specific denial reason
• B. Run istioctl x describe pod against the checkout pod to see which AuthorizationPolicy resources currently select it and what they require
• C. Run istioctl proxy-config secret, since all authorization failures are ultimately certificate problems
• D. Run istioctl profile diff default demo to compare installation profiles
• E. Delete every AuthorizationPolicy in the namespace and see if the call succeeds

Score yourself

☺ Like you're 10: Count what you got right out of thirty, then look at which of the two big domains — troubleshooting or security — actually cost you the most, because that's the one worth another pass before exam day.

Neither the ICA's real item count nor its pass mark is published by the Linux Foundation, so there's no official percentage to compare this score against — the ICA blueprint covers exactly what is and isn't confirmed. Use this table to find your weakest domain, not to predict a real result.

Because this paper is intentionally skewed, a low Traffic Management or Installation score here means less than the same score would on Set 1 or Set 2, which cover both domains at full weight. What this paper actually measures well is whether Troubleshooting and Securing Workloads — nearly two-thirds of these thirty items combined — are solid. If they aren't yet, that's the honest, useful result to walk away with.

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, then go to a real terminal — reading alone doesn't fix a troubleshooting gap.

Beyond the domain pages, the wider revision kit still applies: flashcards for command recall, the self-check quiz for mixed review, the glossary for any term a question assumed you already knew, and the Kubernetes baseline check if any question here leaned on kubectl fluency you're still shaky on. This course doesn't re-teach core Kubernetes — the Kubernetes course's own CKA and CKS material is where that lives in full.

That's the full sitting. If Troubleshooting or Securing Workloads cost you more than a couple of points each, reread the linked pages, run the Lock Down a Mesh Namespace drill for real hands-on reps, then come back and redo just your missed questions in a few days rather than the whole paper again.