Linux Foundation ICA Sample Questions with Explanations

These original sample questions are designed to help you check how the exam topics appear in decision-style prompts. They are not taken from the live exam.

Use these sample questions as a guided self-assessment for Istio Certified Associate (ICA) topics such as traffic management, mTLS, workload identity, gateways, virtual services, destination rules, authorization policy, telemetry, and resilient service behavior. The prompts focus on choosing the mesh control that matches the failure mode or security requirement.

Where these questions fit in the ICA guide

The sample set below is part of the Linux Foundation / CNCF ICA guide path:

• Linux Foundation certification hub
• ICA exam guide
• ICA cheat sheet
• ICA study plan
• ICA FAQ
• ICA resources
• ICA glossary

ICA service-mesh sample questions

Work through each prompt before opening the explanation. ICA questions usually hinge on the difference between Kubernetes routing, Istio traffic policy, identity-based security, and telemetry evidence.

---

Question 1

Topic: Enforcing mTLS between workloads

A platform team has onboarded two namespaces into an Istio mesh. They need service-to-service traffic inside the mesh to require mutual TLS and use workload identity, while avoiding a broad Kubernetes NetworkPolicy rewrite as the first step. Which Istio configuration is most directly aligned with that requirement?

• A. Create a Kubernetes Service of type LoadBalancer for every workload.
• B. Use PeerAuthentication in strict mode for the target scope and ensure clients use mesh-aware traffic policy as needed.
• C. Disable sidecar injection so applications manage TLS directly.
• D. Add more replicas to each Deployment so failed handshakes retry on another pod.

Best answer: B

Explanation: Istio mutual TLS is controlled through mesh security policy, with PeerAuthentication defining the mTLS mode for a mesh, namespace, or workload scope. Strict mode requires mTLS for accepted traffic and ties communication to workload identity instead of only IP reachability.

Why the other choices are weaker:

• A exposes services but does not enforce workload-to-workload mTLS.
• C removes the mesh component that provides transparent mTLS behavior.
• D changes availability characteristics but does not solve authentication or encryption.

What this tests: Istio security policy, mTLS enforcement, workload identity, and the boundary between network exposure and service authentication.

Related topics: PeerAuthentication; mTLS; Workload identity; Mesh security; Sidecars

---

Question 2

Topic: Canary traffic shifting

A team wants to release version v2 of an API to 10 percent of production traffic while keeping 90 percent on v1. Both versions are already deployed and selected by the same Kubernetes Service. Which Istio design best fits?

• A. Change the Kubernetes Service selector to point to v2 for ten minutes, then switch it back.
• B. Create a new namespace for v2 and ask users to manually choose the namespace-specific service name.
• C. Use a liveness probe on v2 to make Kubernetes send a smaller share of traffic.
• D. Define subsets for v1 and v2 and use a VirtualService route with weighted traffic distribution.

Best answer: D

Explanation: Istio can split traffic between service subsets using routing rules. A DestinationRule commonly defines subsets such as v1 and v2, while a VirtualService applies the desired traffic weights for canary or progressive delivery.

Why the other choices are weaker:

• A is a full selector switch, not weighted traffic management.
• B pushes routing to users and does not preserve a single service path.
• C health checks do not express percentage-based routing.

What this tests: VirtualService routing, DestinationRule subsets, and canary traffic control.

Related topics: VirtualService; DestinationRule; Subsets; Canary release; Traffic weights

---

Question 3

Topic: Authorization between services

An orders service should accept requests only from the checkout service account in the same trust domain. Other mesh workloads may resolve the service name, but they should not be authorized to call the workload. Which control is the best fit?

• A. Apply an Istio AuthorizationPolicy that allows the required source identity and denies other callers by default for that workload.
• B. Increase the request timeout so unauthorized callers eventually stop retrying.
• C. Move orders to a different Kubernetes node pool and rely on node separation.
• D. Rename the Kubernetes Service so other teams cannot guess the endpoint.

Best answer: A

Explanation: The requirement is identity-based service authorization. Istio AuthorizationPolicy can make the workload accept traffic only from the intended principal, service account, namespace, or request attributes, depending on the policy design.

Why the other choices are weaker:

• B changes retry behavior but does not enforce access.
• C may help infrastructure isolation, but it is not a mesh authorization rule.
• D relies on obscurity and does not prevent calls from callers that learn the name.

What this tests: AuthorizationPolicy, source identity, service-to-service authorization, and the difference between reachability and permission.

Related topics: AuthorizationPolicy; Service accounts; Workload identity; Trust domain; Access control

---

Question 4

Topic: Troubleshooting routed traffic

Users report that requests to an API sometimes reach the old version even after a VirtualService update. The team needs to confirm which route rule matched, what response codes changed, and whether latency increased for the new subset. What should they check first?

• A. The container image size for both versions.
• B. The number of PersistentVolumes attached to the API pods.
• C. Istio telemetry, route metrics, and traces for the service, subset, response code, and latency dimensions.
• D. The node operating-system release notes before looking at mesh data.

Best answer: C

Explanation: The scenario asks for routing and behavior evidence. Istio telemetry can show request volume, response codes, latency, and route or workload dimensions, while traces can help confirm where requests traveled through the service path.

Why the other choices are weaker:

• A might affect startup or pull time, but it does not explain route matching.
• B is unrelated unless the workload behavior points to storage symptoms.
• D jumps below the mesh layer before checking the evidence most directly tied to the change.

What this tests: Observability-driven troubleshooting in a mesh, including metrics, traces, route behavior, and subset-level symptoms.

Related topics: Telemetry; Tracing; Metrics; VirtualService; Troubleshooting

Independent study note

Tech Exam Lexicon and IT Mastery are independent study tools. They are not affiliated with, endorsed by, or sponsored by the Linux Foundation, CNCF, or any certification body.