Istio Certified Associate (ICA) Practice Exam

What the Istio Certified Associate (ICA) exam covers

• Installation, Upgrades and Configuration128 questions
• Traffic Management225 questions
• Securing Workloads160 questions
• Troubleshooting128 questions

Free ICA practice test questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 641.

1. Question 1Securing Workloads

   What is a service mesh like Istio primarily used for?

   • AManaging service-to-service traffic, security (mTLS), and observability via sidecar proxiesCorrect
   • BProvisioning cluster nodes and scheduling pods onto worker machines
   • CAssigning pod IP addresses and enforcing L3 network policies at the CNI layer
   • DStoring container images and serving them to the cluster's runtime
   ✓ Correct answer: A

   A service mesh inserts a proxy alongside each workload and redirects the pod's traffic through it, which is what lets routing rules, retries, timeouts, mutual TLS and per-request telemetry be applied to an application that was never written to implement any of them. The mesh operates on the connections between services; assigning pod addresses and enforcing L3 policy stay with the CNI plugin, placing pods stays with the Kubernetes scheduler, and holding images stays with the registry.

   Why the other options are wrong

   • BNode provisioning and pod scheduling are Kubernetes control-plane duties, not service-mesh functions.
   • CIP allocation and L3 policy belong to the CNI plugin, not to Istio's L7 mesh.
   • DImage storage is a container registry's job, unrelated to a service mesh.
2. Question 2Traffic Management

   An architect enables aggressive retries on every VirtualService to improve reliability, but observes that transient failures now turn into large traffic surges. What is the best corrective design?

   • AMove all retry logic into application code and remove the mesh's retry, timeout, and circuit-breaking settings entirely
   • BRemove every per-try and overall timeout so retries have unlimited time to complete before the mesh gives up on a request
   • CLimit retry attempts, add per-try timeouts, and pair retries with circuit breaking so retries cannot amplify load during outagesCorrect
   • DIncrease the retry attempts and shorten per-try timeouts further so more retries fire and requests eventually succeed
   ✓ Correct answer: C

   Aggressive retries turn a partial failure into more load on an already failing service, which is how a transient fault becomes an outage. Retries have to be bounded: a small attempt count, a per-try timeout, and circuit breaking on the destination so a service that is failing stops receiving the amplified traffic altogether.

   Why the other options are wrong

   • ARemoving mesh resilience abandons Istio's built-in safeguards and still lets uncoordinated app retries amplify load.
   • BUnbounded timeouts make retry storms worse by letting slow requests pile up indefinitely during an outage.
   • DAdding retries increases the traffic surge that is already overwhelming the backend, worsening the outage.
3. Question 3Securing Workloads

   During migration to STRICT mTLS, some legacy clients outside the mesh still send plaintext to a namespace. You want to allow both during the transition but require mTLS only for one critical workload. What is the correct approach?

   • ASet the mesh-wide PeerAuthentication to DISABLE so no workload requires mTLS during migration, planning to re-enforce it on the critical workload later
   • BDelete every DestinationRule so their subset-level TLS settings stop conflicting with the PeerAuthentication migration and mixed traffic works
   • CSet the mesh-wide PeerAuthentication to STRICT immediately across all namespaces at once so the critical workload is protected right away
   • DSet a namespace-wide PeerAuthentication to PERMISSIVE and a workload-specific PeerAuthentication with mtls.mode STRICT for the critical workloadCorrect
   ✓ Correct answer: D

   The shape that satisfies both requirements is PERMISSIVE at the namespace level with a workload-scoped STRICT policy over it. The namespace default keeps the legacy plaintext callers working while the workloads that have finished migrating enforce mTLS individually, and each workload policy is removed from the exception list as its own callers move inside the mesh.

   Why the other options are wrong

   • ADISABLE turns off mTLS entirely, which neither allows both plaintext-and-mTLS gracefully nor enforces it on the critical workload.
   • BDestinationRules govern outbound client TLS, not the server's accept mode; deleting them does not enable a mixed transition.
   • CImmediate mesh-wide STRICT would break the legacy plaintext clients you must keep working during migration.
4. Question 4Securing Workloads

   Your security baseline mandates a default-deny posture mesh-wide so that any service without an explicit allow rule rejects all requests. How do you implement this in Istio?

   • AApply a PeerAuthentication set to DISABLE in the istio-system root namespace so that every workload without an explicit allow rule rejects all traffic
   • BSet the mesh outboundTrafficPolicy to REGISTRY_ONLY so that any service without an explicit allow rule blocks all unknown inbound traffic
   • CApply an AuthorizationPolicy with action DENY and no rules in the istio-system root namespace so that it matches every request and denies mesh-wide
   • DApply an AuthorizationPolicy with an empty spec (no rules) and action ALLOW in the istio-system root namespace so it applies mesh-wide as default-denyCorrect
   ✓ Correct answer: D

   A mesh-wide default-deny is an AuthorizationPolicy in the root configuration namespace with no rules, which matches nothing to allow and therefore denies everything not covered by a more specific policy. Both parts are load-bearing: the empty rule set is what makes it a deny, and the root namespace is what makes it mesh-wide.

   Why the other options are wrong

   • APeerAuthentication DISABLE turns off mTLS enforcement and does nothing to establish an authorization default-deny posture.
   • BoutboundTrafficPolicy REGISTRY_ONLY restricts egress to registered external hosts, not inbound service-to-service authorization.
   • CAn empty-rules DENY policy denies nothing because it matches no requests; the default-deny idiom is an empty-rules ALLOW policy.
5. Question 5Traffic Management

   You configure a DestinationRule with `trafficPolicy.loadBalancer.simple: LEAST_CONN`. What does this load-balancing algorithm optimize for?

   • ARouting each new request to the upstream endpoint with the fewest active requests at that moment.Correct
   • BRouting each new request to the upstream endpoint with the lowest CPU utilization as reported by metrics.
   • CDistributing requests evenly across endpoints in strict round-robin order regardless of load.
   • DRouting all traffic to the single endpoint with the fastest average response time.
   ✓ Correct answer: A

   The LEAST_CONN load balancing algorithm in Istio (powered by Envoy's least-request LB) tracks the number of active requests to each upstream endpoint and routes new requests to the one with the fewest in-flight requests at that instant. This is more efficient than ROUND_ROBIN for workloads where backend response times vary, because slow endpoints naturally receive less traffic. It does not use external metrics or require any telemetry beyond Envoy's internal connection accounting.

   Why the other options are wrong

   • BLEAST_CONN uses Envoy's internal active-request counters, not external CPU or memory metrics from a monitoring system.
   • CStrict round-robin distribution is ROUND_ROBIN, not LEAST_CONN; round-robin ignores current load on each endpoint.
   • DRouting to the single fastest endpoint describes a different strategy (e.g., P2C or latency-weighted); LEAST_CONN considers all endpoints and distributes load, not concentrating on one.
6. Question 6Securing Workloads

   In Istio ambient mode, which component provides the waypoint proxy functionality for L7 policy enforcement?

   • AA per-pod Envoy sidecar injected into each workload container to apply L7 policy
   • BA standalone Envoy-based waypoint proxy deployed per namespace or service account, separate from ztunnelCorrect
   • Cztunnel running on each node, terminating L4 mTLS and also handling all L7 routing itself
   • Distiod processing every HTTP request inline in the control-plane data path for the namespace
   ✓ Correct answer: B

   Ambient mode splits responsibilities: ztunnel handles L4 mTLS and L4 telemetry at the node level, while L7 capabilities (HTTP routing, L7 AuthorizationPolicy, retries) are provided by waypoint proxies. A waypoint is a separately deployed Envoy that traffic is routed through only when L7 processing is required.

   Why the other options are wrong

   • AAmbient mode's whole point is to avoid per-pod sidecars; L7 policy is handled by a shared waypoint, not an injected sidecar.
   • Cztunnel is the node-level L4 component and does not perform L7 routing; that is the waypoint proxy's job.
   • Distiod is the control plane and does not sit in the data path processing individual HTTP requests.
7. Question 7Traffic Management

   You apply a Sidecar resource with `outboundTrafficPolicy.mode: REGISTRY_ONLY` scoped to one namespace. What is the effect for workloads in that namespace?

   • AThey can only reach hosts known to the mesh registry; unknown external calls are blockedCorrect
   • BThey can reach hosts in the registry but lose all in-mesh service-to-service calls
   • CThey can reach any external host even without a matching ServiceEntry
   • DInbound traffic to those workloads is blocked unless a ServiceEntry exists
   ✓ Correct answer: A

   With outboundTrafficPolicy.mode REGISTRY_ONLY, sidecars only allow egress to hosts known to Istio (Kubernetes Services or those declared via ServiceEntry). Calls to undeclared external hosts are blocked, which is the basis for egress allowlisting.

   Why the other options are wrong

   • BIn-mesh services are in the registry and remain reachable; REGISTRY_ONLY only blocks unknown external hosts.
   • CREGISTRY_ONLY blocks external hosts that lack a ServiceEntry, so it cannot reach arbitrary external hosts.
   • DoutboundTrafficPolicy affects egress only; it has no effect on inbound traffic to the workloads.
8. Question 8Securing WorkloadsSelect all that apply

   Which TWO fields can a RequestAuthentication JWTRule use to constrain or locate the token during end-user authentication? (Choose TWO)

   • AissuerCorrect
   • BfromHeadersCorrect
   • Caction
   • Dselector.matchLabels.app
   ✓ Correct answer: A, B

   A JWTRule constrains the token with issuer, which must equal the token issuer claim, and locates it with fromHeaders or fromParams, which name where the proxy should look. Together they answer which provider is trusted and where the credential arrives, and getting the location wrong produces requests treated as having no token at all.

   Why the other options are wrong

   • Caction is an AuthorizationPolicy field (ALLOW/DENY/CUSTOM/AUDIT), not a JWTRule field.
   • Dselector.matchLabels is a top-level RequestAuthentication field that targets workloads, not a JWTRule field for token validation.
9. Question 9Traffic Management

   A route carries both a retry policy and an abort fault. Which takes effect first?

   • AThe fault, because it is applied before the request would be retriedCorrect
   • BThe retry, because retries are evaluated before any fault is considered
   • CNeither, because a route may not carry both at the same time
   • DBoth simultaneously, so the retried request bypasses the fault
   ✓ Correct answer: A

   The fault is applied first, so a request selected for an abort receives the injected status and the retry policy then reacts to that as it would to any failure. This is worth knowing before running an experiment, because a generous retry policy can mask the fault entirely: the caller eventually succeeds and the test appears to show resilience that a single attempt would not have.

   Why the other options are wrong

   • BA retry happens in response to a failure, so it cannot precede the fault that causes one.
   • CA route may carry both, and the interaction between them is the point of the question.
   • DThey are not simultaneous, and a retried request is subject to the same fault rule.
10. Question 10Installation, Upgrades and Configuration

    A cluster already runs Istio installed with istioctl and the team now wants Helm to manage it. What does that transition require?

    • AA deliberate migration, because neither tool adopts the objects the other createdCorrect
    • BNothing beyond a helm install, which takes ownership of the existing objects
    • COnly a label change on the existing objects to mark them as Helm-managed
    • DNothing at all, because both tools write identical objects and share state
    ✓ Correct answer: A

    istioctl and Helm both produce a working install, but each tracks what it created in its own way and neither adopts the other objects. Moving between them is therefore a planned migration rather than a single command, and running the second tool over the first installation produces conflicting ownership and objects that neither tool will cleanly remove.

    Why the other options are wrong

    • BA helm install does not take ownership of objects it did not create.
    • CLabelling alone does not give Helm the release state it needs.
    • DThe objects are similar but the tracking state is not shared.

Who this Istio Certified Associate (ICA) practice exam is for

This practice set is for anyone preparing for the Istio Certified Associate (ICA) exam at the intermediate level - from first-time candidates building a foundation to experienced Cloud Native practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.

How to use this Istio Certified Associate (ICA) practice exam

1. Start with the free sample questions above to gauge your current baseline.
2. Read the full explanation on every question, including why each wrong option is wrong.
3. Track your weak domains and focus your study where you are losing the most marks.
4. Once you are scoring consistently well, take a timed, full-length mock exam.
5. Use your readiness score to decide when you are ready to book the real Istio Certified Associate (ICA) exam.

Related Cloud Native resources

• Istio Certified Associate (ICA) study guideKey concepts
• Cloud Native practice examsAll Cloud Native
• Certification pathWhere this fits
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• How these questions are written and reviewedMethodology
• Report a problem with a questionCorrections
• KCNA practice examRelated
• KCSA practice examRelated
• OTCA practice examRelated

Istio Certified Associate (ICA) practice exam FAQ