This guide develops the foundational knowledge and configuration reasoning expected of Istio Certified Associate (ICA) candidates. Each concept connects a precise distinction or decision to a worked scenario and a mistake to avoid. Use the examples to explain how configuration changes affect the path, security, and reliability of a request.
Mesh foundations, installation, and upgrades
1. Control plane and data plane responsibilities
The control plane translates configuration and service information into instructions for the data plane. Data-plane components handle application traffic and enforce the configuration they receive. A running control plane therefore does not prove that a particular request follows the intended route; configuration delivery and traffic handling require separate verification.
Worked example: A route changes, but a proxy has not received the update. Requests through that proxy can still follow its previously accepted route.
Mistake to avoid: Treating control-plane readiness as proof that every proxy has current configuration.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
2. Services, workloads, and mesh boundaries
A Kubernetes Service provides a stable destination for a changing set of workload endpoints. Mesh participation belongs to the traffic-handling workloads and infrastructure, not merely to the Service object. Identify the source, destination, and interception points before deciding where an Istio policy can take effect.
Worked example: A Service selects two pods, but only one participates in the mesh. Sharing a Service name does not make their traffic handling equivalent.
Mistake to avoid: Assuming that creating a Service automatically enrolls its pods in Istio.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
3. Sidecar traffic interception
In sidecar mode, a workload has a nearby proxy that handles intercepted inbound and outbound traffic. The application can retain its normal service calls while the proxy applies routing and security behavior. Successful operation requires both the proxy and the interception setup; the presence of a proxy container alone is insufficient evidence.
Worked example: A pod contains an application and an Envoy sidecar. If outbound traffic bypasses interception, its calls will not follow the sidecar's configured routing.
Mistake to avoid: Checking container count without checking whether the intended traffic reaches the proxy.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
4. Ambient transport and application-layer processing
Ambient mode separates transport-level mesh functions from optional application-layer processing. The node-level ztunnel handles the secure transport path, while waypoint proxies provide application-layer capabilities where deployed and used. Distinguish policies that require HTTP awareness from those that can operate using connection and workload identity information.
Worked example: A team needs routing by an HTTP header for an ambient service. It must ensure that the service's traffic traverses an appropriate waypoint.
Mistake to avoid: Expecting transport-only processing to inspect HTTP paths or headers.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
5. Installing with istioctl or Helm
istioctl and Helm offer different ways to express and manage an Istio installation. Whichever method is chosen, distinguish shared definitions, control-plane resources, and separately deployed gateways. Record which tool owns each component so subsequent changes use a consistent configuration source rather than competing installation settings.
Worked example: A gateway is installed through a separate Helm release. Updating the control-plane release does not automatically mean that gateway release was updated.
Mistake to avoid: Assuming one installation action manages every Istio component in the cluster.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
6. Customizing installation components
Installation customization should start with required behavior: mesh mode, gateways, resource allocation, availability, and integration needs. A preset configuration is a starting point, not proof that these needs are met. Inspect the resulting resources and keep intentional overrides explicit so later upgrades can preserve them.
Worked example: An application needs inbound traffic, but the chosen installation creates no ingress gateway. The team must deploy the required gateway component separately.
Mistake to avoid: Assuming a familiar installation preset includes every component the application needs.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
7. Namespace enrollment and revision selection
Enrollment configuration determines which workloads receive sidecar injection or participate in ambient operation. In revision-based sidecar deployments, revision selection identifies the intended control-plane installation. Inspect namespace and workload settings together, and verify the resulting enrollment rather than relying on a label's presence alone.
Worked example: A namespace is assigned to a new control-plane revision. Newly created pods must be checked to confirm that they actually use that revision.
Mistake to avoid: Leaving competing enrollment settings and assuming their combined effect is obvious.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
8. Admission-time injection and existing pods
Sidecar injection occurs when a pod is admitted for creation. Enabling injection for a namespace does not retroactively add a container to pods already running there. Distinguish changing the enrollment configuration from replacing workloads, and plan replacement with normal application availability controls.
Worked example: A namespace has three existing pods when injection is enabled. After a controlled rollout, the replacement pods contain sidecars; the original pods did not change.
Mistake to avoid: Expecting a namespace label change to modify existing pod containers.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
9. Declaring the application protocol
Protocol information helps Istio choose suitable traffic processing. HTTP-aware features require the proxy to recognize HTTP rather than treat the connection as opaque TCP. Check Service port naming or appProtocol declarations against the actual application protocol, using the syntax supported by the installed release.
Worked example: A service exposes HTTP on port 8088 but is treated as opaque TCP. HTTP header routing cannot work until protocol recognition is corrected.
Mistake to avoid: Assuming the port number alone reliably identifies the application protocol.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
10. Resource scope and configuration visibility
An Istio resource's namespace, selectors, attachment, and visibility settings influence where it applies. The existence of a resource does not establish that every workload can use it. Read configuration from the perspective of the affected source or destination, and distinguish resource ownership from the workloads it governs.
Worked example: A routing resource is restricted to its own namespace. A client elsewhere cannot be assumed to receive that routing configuration.
Mistake to avoid: Treating all Istio resources as globally effective regardless of scope.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
11. Canary control-plane upgrades
A canary upgrade introduces a new control-plane revision alongside the existing one, then moves selected workloads to it. This permits comparison before broader migration. Updating the control plane and updating workload proxies are separate steps; verify both configuration delivery and application behavior for the migrated workloads.
Worked example: Only the inventory deployment moves to the new revision first. Its requests succeed before the remaining services are migrated.
Mistake to avoid: Declaring migration complete merely because the new control-plane deployment is healthy.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
12. In-place upgrades and recoverable configuration
An in-place upgrade changes an existing control-plane installation. Preserve the previous configuration, review release compatibility, and account for data-plane updates separately. A useful recovery plan identifies the affected components and their configuration sources; it does not assume that reverting one deployment restores the entire mesh.
Worked example: The control plane upgrades successfully, but workloads still run older proxies. The team verifies supported compatibility before scheduling their rollout.
Mistake to avoid: Assuming all proxies change version automatically with the control plane.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
Routing, external connectivity, and resilience
13. Ingress listeners and route attachment
An ingress gateway's listener defines which traffic it can accept, while routing configuration determines where accepted requests go. For Istio Gateway and VirtualService resources, inspect their association, hosts, ports, and selected gateway workloads together. A listener without an applicable route does not provide a complete application path.
Worked example: The gateway accepts requests for shop.example.test, but the VirtualService references another gateway. The intended backend route is not attached to that listener.
Mistake to avoid: Checking the listener while overlooking route attachment and host agreement.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
14. Ordered HTTP route matching
HTTP routes within a VirtualService are evaluated in order, and the first matching route is used. Put specific conditions before broad fallbacks. A prefix match includes multiple paths, while an exact match selects one path; the choice should reflect the application's URL structure.
Worked example: An /admin prefix route follows an unrestricted fallback. Requests to /admin/settings take the fallback, so moving the specific route earlier resolves the ordering error.
Mistake to avoid: Expecting a later, more specific rule to override an earlier matching rule.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
15. Rewrites and redirects
A rewrite changes the request forwarded upstream while keeping the proxy in the request path. A redirect returns a response instructing the client to make another request. Choose based on whether the public URL should remain stable or the client should learn a different address.
Worked example: Clients request /catalog/items, while the backend expects /items. Rewriting the prefix lets the backend receive /items without requiring a second client request.
Mistake to avoid: Using a redirect when the goal is an internal path translation.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
16. DestinationRule subsets and workload labels
A DestinationRule subset identifies a named group of service endpoints through labels. A route can then select that subset. Subset definitions do not create workloads or change their labels, so verify that the Service's endpoints contain the labels needed by every referenced subset.
Worked example: A route targets subset green, defined by release: green. If every selected pod has release: blue, green has no matching destination endpoints.
Mistake to avoid: Assuming a subset name automatically selects a deployment with the same name.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
17. Weighted traffic shifting
Weighted routes distribute matching requests among destinations according to configured proportions. They describe expected traffic distribution, not an exact sequence of requests or a replica ratio. Evaluate the weights only after confirming that each destination subset has healthy endpoints and receives the intended matches.
Worked example: With weights 85 and 15, 2,000 matching requests would be expected to send about 1,700 to stable and 300 to canary.
Mistake to avoid: Expecting precisely three canary requests in every consecutive batch of twenty.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
18. Header-based routing and trust
Header matches can direct a defined class of HTTP requests to a particular backend, such as a preview release. Establish who can set or modify the header. Routing a request according to a client-controlled value does not authenticate that client or authorize access to the selected backend.
Worked example: Requests containing x-preview: enabled go to a preview subset. A separate authorization rule is needed if preview access must be restricted.
Mistake to avoid: Treating a routing header as proof that the caller is trusted.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
19. Endpoint load balancing and session assumptions
Routing selects a service or subset; load balancing selects an endpoint within that destination. Algorithms distribute requests differently, and connection reuse can affect observed distribution. Consistent hashing can support affinity when a suitable key exists, but it does not make application state shared or durable.
Worked example: A route selects three checkout endpoints. A user's session stored only in one pod can still fail when a later request reaches another pod.
Mistake to avoid: Assuming service-level routing guarantees that a user always reaches the same workload.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
20. Registering external services
A ServiceEntry describes a service outside the platform's normal service registry so mesh configuration can refer to it. Its hosts, ports, protocol, and resolution settings must represent the external destination. Registration supplies service knowledge; it does not itself create network connectivity or override external access controls.
Worked example: An external reporting API is registered, but a network firewall blocks its address. The ServiceEntry cannot make that connection succeed.
Mistake to avoid: Equating external service registration with guaranteed network reachability.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
21. Egress gateway paths and enforcement
An egress gateway provides a designated mesh exit point for selected outbound traffic. The intended path requires routing from the source through the gateway and onward to the external destination. Strong exit restrictions also depend on network controls that prevent workloads from bypassing the gateway.
Worked example: An application is configured to reach an external archive through an egress gateway. If direct outbound connections remain possible, gateway routing alone does not enforce exclusive use.
Mistake to avoid: Assuming an egress gateway automatically blocks every alternate outbound path.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
22. TLS origination to external destinations
TLS origination means a proxy establishes TLS on the upstream connection. Determine whether the application already sends TLS and identify the hop that should initiate it. The upstream server's certificate must also be validated against the intended identity and trusted certificate authorities.
Worked example: An application sends plaintext HTTP to its proxy, which opens HTTPS to reports.example.test. Applying HTTP-to-TLS assumptions to an already encrypted application connection would be incorrect.
Mistake to avoid: Configuring origination without first identifying the protocol arriving at the proxy.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
23. Timeouts as end-to-end budgets
A timeout limits how long a component waits; several components may impose different limits along one request path. The earliest applicable deadline can end the request. Allocate time for upstream processing and any retries while respecting the caller's total budget rather than increasing one timeout in isolation.
Worked example: A caller abandons requests after two seconds, while the proxy allows five. Extending the proxy timeout cannot make that caller wait longer.
Mistake to avoid: Ignoring client deadlines when tuning an upstream route timeout.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
24. Retry eligibility and idempotency
Retries can recover from transient failures, but a failed response does not prove that the first attempt had no effect. Restrict retries to appropriate failure conditions and operations whose repeated execution is safe, or use application-level deduplication. A proxy cannot infer business idempotency from a request's apparent purpose.
Worked example: A payment operation completes, but its response is lost. Retrying without an idempotency key could create a second payment.
Mistake to avoid: Enabling broad retries for state-changing operations without duplicate protection.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
25. Retry amplification across layers
Retries consume extra upstream capacity, especially during an outage. Independent retry policies can multiply attempts across layers. Count the original attempt as well as retries, and align retry budgets across clients, gateways, and services so resilience settings do not worsen overload.
Worked example: A client makes three total attempts, and each can trigger three proxy attempts. One logical request can therefore produce up to nine upstream attempts.
Mistake to avoid: Adding retry counts instead of accounting for nested retry multiplication.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
26. Circuit breaking and local capacity limits
Connection-pool and request limits protect an upstream from excessive concurrent demand. These limits apply at the relevant proxy and upstream cluster, so they should not be mistaken for a single globally coordinated service quota. Interpret rejected or overflowing requests alongside the configured limit and active traffic.
Worked example: Four client proxies each allow up to twenty upstream connections. Together they could permit up to eighty connections, subject to other constraints.
Mistake to avoid: Reading a per-proxy connection limit as a mesh-wide maximum.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
27. Outlier detection and endpoint ejection
Outlier detection identifies endpoints exhibiting configured failure patterns and can temporarily remove them from a proxy's load-balancing choices. It reacts to observed failures and obeys configured ejection limits. Ejecting an endpoint does not repair it, and removing capacity can overload the remaining endpoints.
Worked example: One of four endpoints repeatedly fails and is ejected. Traffic moves to the other three, which must have enough capacity to serve it.
Mistake to avoid: Treating endpoint ejection as a fix for the underlying application failure.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
28. Locality-aware failover
Locality-aware traffic behavior uses endpoint location information and configured priorities to influence destination selection. Failover also depends on available healthy endpoints and the health behavior that makes an endpoint or locality unsuitable. Verify these dependencies rather than assuming a location preference alone creates automatic recovery.
Worked example: Clients prefer endpoints in zone east. If east fails, successful failover requires usable alternative endpoints and configuration that permits selecting them.
Mistake to avoid: Configuring locality preference without validating health detection and alternate capacity.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
29. Delay fault injection
Delay injection deliberately adds latency to selected requests so timeout and dependency behavior can be evaluated. Define the match, delay, and affected fraction carefully. The useful observation is how callers respond to that latency, including cancellation, resource occupancy, and fallback behavior.
Worked example: A test-only header selects requests for a 1.5-second delay. A caller with a one-second deadline times out before receiving the normal response.
Mistake to avoid: Applying a broad delay match when only an isolated test request class was intended.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
30. Abort fault injection
Abort injection makes a proxy return a configured failure for selected traffic instead of completing the normal upstream request. It tests response handling and resilience paths. Distinguish the injected failure from a genuine backend outage when interpreting logs, metrics, or retry behavior.
Worked example: Five percent of a controlled test stream receives an injected HTTP 503. The backend can remain healthy while the caller exercises its failure path.
Mistake to avoid: Diagnosing every injected error as evidence that an upstream workload failed.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
31. Traffic mirroring and side effects
Mirroring sends an additional copy of selected requests to another destination while the primary destination supplies the client-facing response. It can expose a candidate service to realistic inputs. The mirrored application may still perform writes, so its data stores and external effects require deliberate isolation.
Worked example: A mirrored order request reaches a preview service. If that service uses the production payment integration, the copied request could cause an unintended charge.
Mistake to avoid: Assuming an ignored mirror response means the mirrored request has no effects.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
32. HTTP routing versus connection routing
HTTP routing can inspect application-level fields such as paths and headers. Opaque TCP routing operates on connections and cannot distinguish requests by an HTTP path. Choose routing features according to what the proxy can actually observe at that point in the traffic path.
Worked example: Two database operations share one TCP connection. An HTTP path rule cannot separate them because there are no visible HTTP requests to match.
Mistake to avoid: Applying HTTP routing expectations to an opaque connection-oriented protocol.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
33. Traffic policy scope and overrides
DestinationRule traffic policies can be expressed at service, subset, and port-specific scopes. Narrower applicable settings can alter behavior inherited from a broader policy. Read the effective configuration for the selected destination and port rather than assuming the top-level policy describes every route.
Worked example: A service has a general connection policy, but its preview subset defines a different limit. Requests routed to preview must be assessed using that applicable override.
Mistake to avoid: Inspecting only the service-level policy when a subset or port override exists.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
Identity, authentication, and authorization
34. Mutual TLS and workload authentication
TLS protects a connection and authenticates the server when certificate verification is performed. Mutual TLS additionally authenticates the client through a certificate. In a mesh, this supplies workload identities that authorization can use; an authenticated connection still needs a separate decision about permitted access.
Worked example: The ledger service recognizes the caller's workload certificate. It can still deny that caller permission to invoke the settlement endpoint.
Mistake to avoid: Equating successful mutual TLS with authorization to perform every operation.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
35. Service accounts and workload identity
Istio workload identity commonly incorporates the trust domain, namespace, and Kubernetes service account. Different workloads using the same service account may therefore share the same identity for policy purposes. Design access rules around the intended identity boundary rather than deployment names alone.
Worked example: Two deployments in the same namespace use the same service account. An identity-based allow rule can grant both the same access.
Mistake to avoid: Assuming each deployment automatically receives a unique authorization identity.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
36. STRICT and PERMISSIVE peer authentication
PeerAuthentication controls how inbound workload connections are authenticated. STRICT requires mutual TLS on the governed connection; PERMISSIVE permits both mutual TLS and plaintext. A permissive transition can accommodate clients during migration, but it does not establish that every accepted request has a verified mesh identity.
Worked example: A legacy plaintext client reaches a permissive workload. After that workload requires STRICT mutual TLS, the same plaintext connection is no longer acceptable.
Mistake to avoid: Treating PERMISSIVE as a guarantee that all accepted traffic is encrypted.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
37. Outbound TLS and inbound expectations
Inbound authentication requirements and outbound TLS behavior must agree. Istio can automatically select mesh mutual TLS for suitable destinations, while explicit DestinationRule settings can change the client's behavior. Diagnose the two ends together before adding an explicit TLS override.
Worked example: A destination requires mutual TLS, but a client's applicable DestinationRule disables TLS. Correcting that mismatch is necessary before requests can succeed.
Mistake to avoid: Changing only the destination's policy while overlooking an incompatible client-side override.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
38. JWT signatures and claim validation
A JWT's encoded payload is readable, but decoding it does not verify its authenticity. Validation requires a trusted signing key and checks for the configured issuer, audience, and relevant time claims. A valid signature from an unrelated issuer does not make a token acceptable to this service.
Worked example: A signed token targets audience analytics, while the service expects billing. Its signature can be valid while audience validation rejects it.
Mistake to avoid: Trusting displayed JWT claims merely because the token decodes successfully.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
39. RequestAuthentication and missing tokens
RequestAuthentication describes how presented JWTs are validated. By itself, it does not generally require every request to present a token. Requiring an authenticated request principal needs an appropriate authorization policy in addition to token validation.
Worked example: A service validates tokens from its configured issuer. A request with no token needs a separate authorization requirement if anonymous access must be rejected.
Mistake to avoid: Assuming that configuring a JWT issuer automatically makes the endpoint require login.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
40. Authorization policy attachment
AuthorizationPolicy scope determines which workloads or supported targets enforce its rules. Namespace placement, selectors, and applicable target references matter. In ambient deployments, application-layer rules must also reach the component that performs the relevant inspection; do not assume sidecar attachment semantics fit every topology.
Worked example: A policy selects app: ledger, but the intended workloads carry app: accounting. The selector does not govern those workloads.
Mistake to avoid: Evaluating rule content before confirming that the policy attaches to the intended target.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
41. ALLOW and DENY policy interaction
For workloads governed by ALLOW and DENY policies, a matching DENY rejects a request. Once an ALLOW policy applies, a request must match an applicable ALLOW rule to pass that stage. Multiple ALLOW policies provide alternative ways to match; a DENY is not canceled by an ALLOW.
Worked example: An ALLOW permits a client service, but a DENY blocks its DELETE requests. Its GET can pass while its DELETE is rejected.
Mistake to avoid: Assuming an ALLOW rule overrides a matching DENY rule.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
42. Authorization rule logic
Within an authorization rule, source, operation, and condition requirements combine to describe an acceptable request. Alternative entries within a relevant list can broaden the match. Translate a rule into plain logical statements before relying on it, especially when adding another source or method.
Worked example: A rule permits either reader-a or reader-b, requires GET, and requires a department claim. POST from reader-a still fails that rule.
Mistake to avoid: Assuming that matching one part of a rule satisfies all its required conditions.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
43. Methods, paths, and inspection capability
HTTP methods and paths support precise operation-level authorization when the enforcing proxy can inspect HTTP. Opaque TCP does not expose those fields. Use conditions appropriate to the observed protocol, and account for path normalization so the policy and application interpret the protected operation consistently.
Worked example: An HTTP-aware proxy permits GET on /reports but rejects POST there. The same method rule cannot meaningfully identify operations inside opaque TCP traffic.
Mistake to avoid: Using HTTP fields as though they were available on every connection.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
44. Peer principals and request principals
A peer principal identifies the authenticated workload on a mutual TLS connection. A request principal identifies an authenticated request identity, commonly derived from a validated JWT. They answer different questions: which workload connected and which request identity it presented.
Worked example: A frontend calls billing using its workload identity and a customer's JWT. Billing can require both an approved frontend and an authenticated customer.
Mistake to avoid: Substituting a customer JWT identity for the connecting workload's identity.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
45. JWT claims as authorization conditions
Validated JWT claims can express attributes used by authorization rules, but their meaning depends on the trusted issuer. Require the relevant claim and accepted value explicitly. A token's overall validity does not imply that its holder belongs to every role or group recognized by the application.
Worked example: A valid token contains department: sales. A policy requiring department: finance rejects its request to the finance endpoint.
Mistake to avoid: Granting access based on an arbitrary unvalidated header carrying a role name.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
46. TLS termination at an ingress gateway
TLS termination ends the client's encrypted connection at the gateway, enabling the gateway to inspect HTTP and apply application-layer routing. The gateway-to-backend connection is a separate hop with its own security configuration. Protecting the public hop does not establish the security of the internal hop.
Worked example: A gateway accepts HTTPS and routes by /invoices. The connection from that gateway to the invoice workload must be assessed separately for mesh mutual TLS.
Mistake to avoid: Assuming edge HTTPS automatically encrypts every downstream connection.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
47. TLS passthrough and SNI routing
With TLS passthrough, the gateway forwards encrypted traffic without terminating the application's TLS session. It can use available handshake information such as SNI for routing, but it cannot inspect encrypted HTTP paths or headers. The backend remains responsible for presenting the appropriate certificate.
Worked example: A gateway routes SNI archive.example.test to the archive backend. It cannot separately route /download because that path remains encrypted.
Mistake to avoid: Combining passthrough with an expectation of HTTP path inspection at the gateway.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
48. Certificate validation and renewal
Certificate validation checks trust, identity, and validity time; renewal replaces credentials before they become unusable. Inspect both the certificate being presented and the trust held by the peer. A renewed certificate can still fail if it represents the wrong identity or chains to an untrusted authority.
Worked example: A server has an unexpired certificate for old.example.test, but the client expects api.example.test. Renewal alone will not resolve the identity mismatch.
Mistake to avoid: Checking only expiry while ignoring identity, trust chain, and credential delivery.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
Configuration and request-path diagnosis
49. Valid configuration versus effective configuration
Troubleshooting begins by separating configuration that was submitted, accepted, and made effective at the relevant proxy. Static analysis can reveal inconsistent references or suspicious settings, but syntactic validity does not prove the intended behavior. Inspect applicable resources and the resulting data-plane configuration together.
Worked example: A VirtualService is valid YAML and exists in Kubernetes, but it references the wrong gateway. Its existence does not establish the intended route.
Mistake to avoid: Stopping diagnosis once the API server accepts the resource.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
50. Control-plane health and dependencies
A control-plane deployment must be able to run, access its dependencies, and process service and configuration information. Investigate readiness, events, logs, resource pressure, and API connectivity when it is unhealthy. Separate an installation failure from a healthy control plane rejecting one problematic configuration.
Worked example: istiod repeatedly restarts under memory pressure. Editing a route will not resolve the underlying control-plane resource problem.
Mistake to avoid: Interpreting every missing route as an application configuration error.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
51. Proxy synchronization and rejected updates
A connected proxy can still have stale or rejected configuration. Compare proxy synchronization information with control-plane and proxy logs to identify delivery or acceptance problems. A rejection may leave the previous accepted configuration active, explaining why observed behavior differs from the newest resource.
Worked example: A proxy rejects an update and continues serving its prior configuration. The newest route in Kubernetes therefore does not describe its actual request handling.
Mistake to avoid: Assuming a connected proxy has accepted every configuration update.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
52. Listeners, routes, clusters, and endpoints
Trace the proxy's forwarding chain: a listener accepts traffic, an applicable route chooses an upstream cluster, and that cluster uses endpoints. Inspecting these stages narrows where configuration or discovery broke. Use the proxy actually handling the failing request rather than an unrelated healthy instance.
Worked example: The route references an upstream cluster, but that cluster has no usable endpoints. The failure lies beyond route matching and before backend processing.
Mistake to avoid: Inspecting only route configuration while ignoring upstream endpoint state.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
53. DNS failures versus connection failures
Name resolution precedes many connections. Determine whether the client resolves the intended hostname before investigating routing or authentication. Short service names depend on namespace and search context, while fully qualified names reduce ambiguity. A resolved address still needs a reachable and correctly configured destination.
Worked example: A client in namespace web requests inventory, but the Service is in warehouse. Using the intended qualified service name resolves the namespace mismatch.
Mistake to avoid: Diagnosing TLS before confirming that the hostname resolves to the intended destination.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
54. Service selectors and endpoint readiness
A Service's selector must match the intended pods, and endpoint readiness affects which destinations are usable. Inspect endpoint information alongside pod labels and readiness conditions. A healthy proxy cannot forward successfully to a service that has no eligible application endpoints.
Worked example: A Service selects tier: api, but its pods have tier: backend. Correcting the selector establishes endpoints for the intended workloads.
Mistake to avoid: Assuming a Service has backends because its object and address exist.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
55. Service ports and application listening ports
Follow port mappings from the client-facing Service port to the workload's target port and actual listening socket. Distinguish these from gateway listeners and proxy administration ports. A correct hostname and route still fail if the selected application port has no listener.
Worked example: A Service exposes port 80 and forwards to 8080, but the application listens on 9090. Changing the target mapping to the intended listener resolves that mismatch.
Mistake to avoid: Assuming the Service port must equal the application's listening port.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
56. Locating a TLS handshake failure
A handshake failure occurs before a normal application response, so isolate the failing hop and compare its client and server expectations. Check plaintext versus TLS, mutual TLS requirements, certificate identity, trust, and validity. Do not weaken authentication merely to hide a mismatch.
Worked example: Edge HTTPS succeeds, but the gateway's connection to a STRICT backend uses plaintext. The failing hop is gateway-to-backend, not client-to-gateway.
Mistake to avoid: Changing the public certificate when the failure is on an internal connection.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
57. HTTP status and proxy response flags
An HTTP status identifies an outcome, but proxy response flags can explain how that outcome arose. Distinguish locally generated proxy errors from upstream application responses. For Envoy-based paths, flags such as NR for no matching route or UF for an upstream connection failure provide useful diagnostic direction.
Worked example: A response includes NR. Inspecting route and host matching is more useful initially than searching the backend for an application exception.
Mistake to avoid: Assuming every HTTP 503 was generated by the destination application.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
58. Access logs and request correlation
Access logs can connect route selection, upstream destination, response status, flags, and duration for an individual request. Correlate entries using available request identifiers and timestamps across the relevant proxies. Confirm that logging is enabled where needed; missing log entries are otherwise weak evidence.
Worked example: The same request identifier appears at ingress and the service proxy. Their destinations and timings show where the request was forwarded and delayed.
Mistake to avoid: Treating an absent log entry as proof that no request occurred.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
59. Metric rates, error ratios, and distributions
Counters accumulate events, so compare changes over a defined interval rather than treating a lifetime total as a current rate. Compute error ratios using matching traffic populations and time windows. Latency distributions reveal slow requests that averages can conceal; source and destination measurements may represent different observations.
Worked example: During one interval, fifteen of 3,000 requests fail. The error ratio is 15 divided by 3,000, or 0.5 percent.
Mistake to avoid: Dividing errors from one service or interval by requests from another.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
60. Trace propagation and sampling gaps
Distributed tracing relates spans across a request path when trace context is propagated. Applications often need to carry incoming context into outgoing calls, and sampling means some requests produce no retained trace. Use traces to locate delays, then corroborate missing or incomplete spans with logs and metrics.
Worked example: A frontend starts an unrelated trace for its backend call instead of forwarding context. The two services appear disconnected despite handling the same user request.
Mistake to avoid: Concluding that an untraced service was never called.
Source reference: Istio Certified Associate (ICA) - Linux Foundation - Education
Sources
Sources checked:
All study guides