Istio Certified Associate (ICA, CNCF/Linux Foundation) (ICA) (ICA) — Questions 1–75

idleTimeout is a genuine field within the http connectionPool configuration, specifying how long an unused connection is retained before being closed. It satisfies the stem's requirement by belonging to that connectionPool block, alongside http2MaxRequests and maxRequestsPerConnection.

The `trafficPolicy.connectionPool.tcp.maxConnections` field in a DestinationRule caps concurrent TCP connections to the payment service at 100. Istio applies this limit at the sidecar proxy when initiating upstream connections, satisfying the stem's concurrency constraint without altering the service itself.

Istiod's control plane watches Istio configuration resources such as AuthorizationPolicy and translates them into Envoy-native configuration, then pushes updates to each sidecar through the xDS protocol. This distribution mechanism satisfies the stem's requirement that policies reach every sidecar without manual intervention or per-pod configuration.

ServiceEntry registers the external database host in the mesh registry, while DestinationRule defines the TLS origination policy for that host. Together they satisfy the stem's constraint: enabling mesh egress to an external database over TLS.

HTTPRoute attaches to a Gateway and defines path-prefix matching rules, satisfying the requirement for path-based routing. Unlike TCPRoute, which operates at layer 4 without HTTP awareness, HTTPRoute provides layer 7 host, header and path matching. Istio's Gateway API implementation reconciles HTTPRoute resources to configure Envoy route configurations.

When the configured timeout elapses without a response, Envoy terminates the upstream request and returns HTTP 504 Gateway Timeout to the caller, distinguishing it from a 503 returned by fault injection or an unavailable endpoint.

The Gateway's TLS section configures SNI-based routing by matching the server name presented during the TLS handshake to a credentialName, directing traffic to the appropriate hosts. Without it, the gateway cannot distinguish virtual hosts on shared ports.

Mismatched subset labels between DestinationRule and VirtualService cause routing failures, since the VirtualService references a subset name that the DestinationRule must define against matching pod labels. Verifying these align resolves the common misconfiguration where traffic silently falls back or fails, satisfying the stem's requirement to correct faulty routing.

http2MaxRequests limits concurrent streams per connection and maxRequestsPerConnection forces a connection to be recycled after a set number of requests, which together govern HTTP/2 connection reuse and capacity. Setting these values is how operators tune multiplexing and connection lifecycle at the pool level. This satisfies the connection reuse requirement while the outlier detection block handles ejection.

DestinationRule configures mTLS for traffic to a service by setting the TLS mode within its trafficPolicy, satisfying the requirement to control mutual authentication between sidecars. It governs the client side of a connection, enforcing STRICT or PERMISSIVE modes, which is why it is one of the two resources that manage mTLS settings.

AuthorizationPolicy source.ipBlocks matches the originating IP against the specified CIDR ranges, so only requests from 10.0.0.0/24 are permitted to reach the payments service. Other sources are denied, enforcing the security team's origin restriction at the Envoy layer.

consecutive5xxErrors sets how many sequential server errors an endpoint must return before it is ejected from the load-balancing pool. This satisfies the resilience constraint by removing unhealthy hosts quickly, preventing repeated failures reaching a degraded instance.

Five consecutive 5xx responses is the default threshold before Istio's outlier detection ejects a host from the load-balancing pool. This satisfies the stem's request for the out-of-the-box `consecutive5xx` value, which applies per host within the interval, requiring no explicit configuration in the DestinationRule.

TCP is the correct protocol value for a ServiceEntry describing a raw TCP service, since Istio then applies TCP-level routing and load balancing rather than HTTP inspection. It satisfies the stem's constraint of matching the service's actual transport.

The istio-proxy sidecar intercepts inbound and outbound pod traffic via iptables redirection, enabling Envoy to apply mTLS, routing and telemetry without application changes. This satisfies the stem's requirement for the container's primary function: transparent traffic interception at the pod network layer.

Setting `trafficPolicy.connectionPool.tcp.maxConnections` caps concurrent TCP connections to the 'orders' service, directly satisfying the stem's requirement to limit connection count. Istio's connection pool settings apply per destination host, so this field throttles simultaneous connections at the sidecar before requests reach the workload.

The proxy image is a global mesh-wide setting, so it belongs under spec.values.global.proxy.image in the IstioOperator resource. Placing it there overrides the default sidecar image for every injected workload rather than a single namespace or deployment.

Envoy Proxy runs as the sidecar enforcing AuthorizationPolicy decisions at the workload level. Istiod distributes the policy configuration, but the actual allow or deny enforcement on each request happens inside the Envoy filter chain, satisfying the requirement for workload-level enforcement.

Mirroring sends a duplicate of live production traffic to the new service version while the primary still serves real responses, letting you test the new version under genuine load without impacting users. This matches the requirement precisely.

ROUND_ROBIN is Istio's default load balancing policy when a DestinationRule omits the field, distributing requests sequentially across healthy endpoints in each subset. This satisfies the stem's constraint of no explicitly specified policy, so traffic spreads evenly without requiring any additional configuration.

A VirtualService binds routing rules to the Gateway, matching hosts and directing inbound traffic to mesh services. Without it, the Gateway accepts connections but has no routes, so external traffic cannot reach workloads. Both components together satisfy the requirement for external ingress.

Gateway defines the listener configuration and ports that expose the mesh to inbound traffic, satisfying the requirement for a dedicated entry point. It binds to a GatewayClass and routes requests onward via HTTPRoute resources, separating infrastructure-level ingress from application routing rules.

The default profile provides the full set of capabilities with no restrictions, so it supports the redundancy and throughput a production deployment demands. Restricted profiles strip features for security or testing, which would undermine the high availability and performance the stem requires.

The timeout field in an HTTP route specifies the maximum time a request can take before it is aborted. When the timeout is exceeded, Istio returns a 504 Gateway Timeout to the client. Setting this field to 5s ensures that requests taking longer than 5 seconds are terminated with the appropriate error. This directly fulfills the scenario's requirement.

PERMISSIVE mode accepts both mutual TLS traffic from sidecar-injected workloads and plaintext traffic from sources without sidecars, easing migration. It does not enforce mTLS; STRICT is required for that, so plaintext connections remain accepted on the same port.

The retryOn field lists the conditions, such as connect-failure, reset or gateway-error, that trigger Istio to retry a failed request to the destination. It defines when retries occur, while attempts and perTryTimeout govern how many and how long.

A Gateway configures the ingress listener at the mesh edge, defining ports, hosts and TLS for incoming external traffic. It satisfies the stem's requirement to expose a service outside the mesh, with a VirtualService binding routes to it.

A RequestAuthentication policy only validates JWTs when one is present; it does not itself reject requests lacking a token. Because no JWT is supplied, the policy performs no validation and the request passes through, satisfying the stem's scenario. Rejection requires a separate AuthorizationPolicy with JWT rules configured.

DestinationRule hosts traffic policies for a service, including connectionPool settings that cap concurrent connections and pending requests to order-service. This limits in-flight connections, preventing one slow dependency from exhausting resources and causing cascading failures across the mesh.

This rule correctly combines a source principal match with an operation match. The 'from' field restricts the source to the specified SPIFFE identity, and the 'to' field restricts the request to HTTP GET on the exact path. This enforces both identity-based and method/path-based access control in a single AuthorizationPolicy rule.

Setting replica counts for Istiod belongs under the pilot component, since Istio's control plane daemon is named pilot internally. The IstioOperator schema nests Kubernetes-specific settings beneath `k8s`, so `spec.components.pilot.k8s.replicaCount` is the precise path that satisfies the stem's requirement to scale Istiod replicas.

The istio-system namespace hosts Istio's control plane components, including istiod, which handles service discovery, configuration distribution, and certificate management. It is not where application workloads or data-plane sidecars run, so it satisfies the requirement for a dedicated namespace isolating control plane functions.

A ServiceEntry with location MESH_EXTERNAL registers an external endpoint so Istio's traffic policies, mTLS origination and telemetry still govern egress calls, satisfying the stem's multi-cluster requirement that services outside the mesh remain manageable by Istio rather than bypassing the sidecar entirely.

The injector is an admission webhook that intercepts pod creation requests; when a namespace carries the istio-injection=enabled label, it mutates the pod spec to add the Envoy container and its configuration volume, satisfying the requirement that sidecars be added automatically rather than manually.

Fault injection scopes the effect using a percentage object containing a value field, which specifies the proportion of requests that receive the fault. This satisfies the constraint of applying the fault to only part of the traffic rather than all of it.

Hostnames a Gateway should accept are defined in the Gateway's own listener configuration, where each listener specifies its hostname and certificate binding. Configuring them here satisfies the stem's requirement directly, since the Gateway resource itself holds the accepted-hostname settings rather than a separate policy or DNS record.

Outlier Detection counts consecutiveGatewayErrors, which covers gateway failures such as connection refused or reset, and ejects the host once the threshold is exceeded. This satisfies the stem's requirement that gateway failures be a common ejection cause.

istioctl analyze inspects the cluster's Istio configuration resources and reports errors, warnings and misconfigurations, such as invalid virtual services or conflicting gateways. It directly satisfies the requirement to troubleshoot configuration issues by analysing the cluster for errors.

When the configured timeout is shorter than the service's average response latency, Envoy aborts the upstream request before the backend can reply, returning a 504 to the caller. This directly satisfies the stem's constraint: a timeout below average latency produces gateway timeout errors.

The trust domain forms the root of the SPIFFE identity URI embedded in every workload certificate, appearing as spiffe://<trust-domain>/ns/... in the SAN. It establishes which identities are trusted within the mesh, so mismatched trust domains reject mTLS handshakes.

Outlier detection ejects individual unhealthy hosts from the load-balancing pool based on consecutive 5xx errors or gateway failures, whereas circuit breaking trips at the connection-pool level, rejecting requests once pending or active connection limits are exceeded. The stem's contrast between host health and request load is satisfied precisely by this split.

Istio's VirtualService resource supports fault injection natively, letting you configure HTTP delays or aborts against a host without altering application code. This satisfies the stem's requirement for a valid fault injection method, since the delay is applied at the service-mesh proxy layer during request routing.

Connection pooling is configured through the connectionPool settings within trafficPolicy, letting you cap HTTP/1.1 pending requests, HTTP/2 concurrent streams, and TCP connections per host. This satisfies the stem's requirement for a supported trafficPolicy feature, as these limits are applied to individual destination hosts.

The spec.components.ingressGateways field configures gateway deployments directly, letting you set replica counts, resource requests and limits, and node selectors for the ingress gateway pods. It satisfies the requirement to configure ingress gateway resources through the IstioOperator CR's component-level overrides.

The rules.when field holds match conditions evaluated against request attributes, including verified JWT claims via request.auth.claims. This satisfies the constraint of restricting access by claim values, since the JWT must first be validated by a RequestAuthentication policy before those claims are trusted.

Istio's VirtualService defines traffic routing rules, including weighted destinations that split requests between subsets. Specifying a 90/10 weight distribution across two versions achieves the canary rollout, which no other Istio resource exposes as a routing control.

from is one of the three rule fields in an Istio AuthorizationPolicy, defining the source of the request via source principals, namespaces, or IP blocks. It satisfies the stem's requirement for a valid rules-section field.

A SPIFFE ID follows the spiffe:// URI form, where the trust domain is the authority component identifying the issuing trust root, followed by the workload path; the trust domain is therefore one of the three constituent parts.

MeshConfig telemetry settings control whether Envoy proxies generate metrics, access logs and traces mesh-wide. Enabling these settings is essential because without them the control plane collects no telemetry, leaving the mesh effectively unobservable regardless of other configuration.

PeerAuthentication defines the mTLS mode for workloads on the receiving side, so verifying it confirms traffic is encrypted. Its mtls mode enforces mutual TLS between sidecars, satisfying the requirement that service traffic is encrypted via mTLS.

Load balancer policy directly governs how incoming connections are spread across backend pods, satisfying the requirement for a traffic-distribution configuration. In Kubernetes, the Service's `externalTrafficPolicy` and `internalTrafficPolicy` settings determine whether traffic is routed to all endpoints cluster-wide or only to pods on the receiving node, altering distribution behaviour.

Without any PeerAuthentication policy, Istio's mesh-wide default is PERMISSIVE mode, so sidecars accept both plaintext and mTLS traffic simultaneously. This satisfies the stem's condition of no policy applied, allowing gradual migration without breaking non-mesh clients.

AuthorizationPolicy rules define the allow, deny and custom conditions applied to inbound requests at the workload. This satisfies the constraint because traffic is only accepted when an ALLOW rule matches; absent any matching rule, the request is rejected by default.

RANDOM is a valid Istio load balancing policy, distributing requests across healthy endpoints without weighting. It satisfies the question's requirement for a genuine Istio policy, alongside ROUND_ROBIN and LEAST_REQUEST. Istio also offers PASSTHROUGH and consistent hash-based options, but RANDOM remains a core supported policy.

A ServiceEntry registers api.example.com in the mesh's internal service registry so the sidecar has a route and can allow the connection. Setting the Sidecar's outboundTrafficPolicy to REGISTRY_ONLY restricts egress to only services present in the registry, so every other unknown host stays blocked. This is the supported way to selectively permit external hosts without opening the mesh to all destinations.

A VirtualService can route requests, matching on host, path, headers or other attributes and directing traffic to destination subsets or versions. Routing is one of its core request-handling actions, satisfying the question's requirement alongside fault injection, redirects and rewrites.

kubectl get virtualservices queries the Kubernetes API for VirtualService custom resources in the active namespace, listing them in a table. It satisfies the listing requirement because VirtualServices are Kubernetes CRDs, so kubectl, not istioctl, performs namespace-scoped resource enumeration.

This command removes the `istio-injection` label and adds the `istio.io/rev` label pointing to the canary revision. Removing the old label ensures that only the new revision's injection webhook applies to pods in the namespace. The `--overwrite` flag allows updating existing labels. This is the correct approach to migrate a namespace to a canary revision without disrupting existing traffic.

PeerAuthentication governs mutual TLS enforcement between workloads, so a STRICT policy in either namespace can reject plaintext traffic from the other service. Checking it confirms whether mTLS mode blocks the cross-namespace connection, satisfying the requirement to verify connectivity across namespace boundaries.

A timeout of 2s declared in the VirtualService route rule caps how long Envoy waits for the search service before returning an error, delivering the required fail-fast behaviour. The timeout applies per route, so the request is abandoned at two seconds rather than hanging.

Header-based matches in a VirtualService let you route only requests carrying a specific test header to the fault-injected subset, leaving ordinary production traffic untouched. This satisfies the stem's constraint of testing fault injection in production without disrupting live users, since Istio evaluates match conditions before applying the abort or delay rule.

The `connectionPool` field in a DestinationRule defines TCP and HTTP connection limits, including `maxConnections` and `http1MaxPendingRequests`, which cap concurrent connections to the service. This directly satisfies the requirement to limit concurrent connections, unlike traffic policy fields governing load balancing or outlier detection.

A Gateway resource with TLS mode MUTUAL enables mutual TLS termination at the ingress gateway. The credentialName must reference a Kubernetes secret containing the server certificate, private key, and CA certificate. This enforces client certificate validation for external clients connecting to the public gateway, while the private gateway remains unchanged because the Gateway resource is applied only to the public gateway's selector.

This field specifies the container registry hub for all Istio images. Setting it to your private registry ensures that Istio pulls images from that location. It is the primary way to override the default `docker.io/istio` hub. Without this, the installation would attempt to pull from the public registry, which may fail in an air-gapped environment.

Istio evaluates DENY policies before ALLOW policies, so any matching DENY rule blocks the request regardless of an ALLOW rule that would otherwise permit it. This deny-overrides evaluation order satisfies the scenario where both actions exist in the same namespace.

The cacerts resource holds the trusted root certificates Istio uses to validate workloads. Supplying a custom CA's root certificate there lets the mesh trust that authority, satisfying the requirement to define the root certificate for a custom CA.

VirtualService traffic routing rules can rewrite the request URI before forwarding, altering the path or host the destination workload receives. This is distinct from header manipulation or retries, which are separate actions within the same routing configuration.

proxy-status shows whether each proxy is in sync with istiod, ruling out stale configuration. Then proxy-config listeners and routes on the specific client pod reveal whether the expected listener exists for the destination port and whether a route matches the destination host. This sequence directly inspects the running proxy's state, which is exactly what the troubleshooting scenario requires.

The istio-remote-secret stores the remote cluster's API server credentials, enabling the shared control plane to authenticate and manage that cluster's services and endpoints. This satisfies the multi-cluster requirement by granting the primary control plane secure access to remote API servers for service discovery and configuration propagation.

Raising consecutive5xx requires multiple successive failures before ejection, preventing a single transient error from removing the pod. Increasing the interval lengthens the analysis window, so failures must persist across a longer period. Together these satisfy the stem's demand that ejection occur only after consistent failure.

The abort fault injects a specified HTTP status code, so setting abort with httpStatus 503 and percentage 20 returns 503 for one fifth of catalog requests. This directly satisfies the stem's requirement to simulate service unavailability rather than delay.

istioctl analyze inspects the cluster's Istio configuration and reports validation errors, warnings and deviations from best practise. It is the dedicated command for confirming that deployed resources are valid and conform to recommended configuration standards.

Under STRICT PeerAuthentication, the client sidecar initiates mTLS handshakes with the destination workload, since plaintext is rejected. This satisfies the stem's constraint by describing the client-side action required when strict mutual TLS is enforced mesh-wide.

The SPIFFE-style identity `cluster.local/ns/default/sa/my-service` is the exact principal format Istio expects in an AuthorizationPolicy, encoding trust domain, namespace and service account. It satisfies the stem's requirement for correct principal syntax, unlike bare service names or DNS hostnames, which Istio cannot match against workload identities.

A PeerAuthentication with a selector targets only the labelled workload's sidecars, overriding the mesh-wide default for that pod. The workload's own policy takes precedence, so it can set mTLS to PERMISSIVE or DISABLE while the global STRICT policy remains for everything else.