Istio Certified Associate (ICA, CNCF/Linux Foundation) (ICA) (ICA) — Questions 76–150

`host` is a required DestinationRule field, specifying the destination service's fully qualified domain name or short name that traffic policies apply to. It satisfies the stem's demand for valid DestinationRule fields, since every DestinationRule must declare which service it governs before defining subsets, load-balancing or connection-pool settings.

A timeout bounds how long a caller waits, releasing the thread, connection and memory tied to that request once the deadline passes. This directly prevents resource exhaustion from hanging requests, satisfying the stem's stated purpose.

VirtualService HTTP route rules expose a headers field supporting request and response manipulation, including set, add and remove operations. This is the only Istio resource that rewrites incoming request headers before forwarding to the destination.

The rewrite field strips or replaces a matched URL prefix before forwarding the request upstream, so the backend receives the path it expects. This satisfies the requirement to remove the prefix without altering the client-facing route.

Multiple AuthorizationPolicies targeting one workload combine additively: a request is allowed if any policy's ALLOW rule matches, giving OR semantics. This satisfies the stem's union requirement, so adding policies only widens access rather than intersecting it.

Defines the simple load balancing algorithm (e.g., ROUND_ROBIN).

Headers match on HTTP request header values, satisfying the stem's requirement for valid VirtualService match conditions. Istio evaluates them alongside URI, method, and source labels within the match block, enabling routing decisions based on custom or standard headers such as authorisation tokens or content type.

Envoy increments upstream_rq_timeout each time a request to an upstream cluster exceeds the configured timeout before a response arrives. It counts timed-out upstream requests specifically, distinguishing them from connection failures or resets, which are tracked by separate counters.

A Sidecar resource with an egress policy applies host-level and port-level rules to outbound traffic from selected workloads, restricting which external services pods may reach. This satisfies the egress control requirement by enforcing allowlists at the sidecar proxy.

DestinationRule outlierDetection continuously analyses each endpoint's 5xx responses and ejects the offending pod from the load-balancing pool once consecutive failures breach the configured threshold, satisfying the requirement to remove misbehaving pods automatically. Istio's Envoy sidecars enforce this at the data plane, so no application code changes are needed.

ServiceEntry registers external hosts in Istio's internal service registry, letting mesh sidecars resolve and route to api.google.com. Without it, the sidecar's outbound traffic policy blocks unknown external destinations, so this satisfies the requirement to reach an external API.

A namespace-wide PeerAuthentication policy without a selector applies to every workload in that namespace, taking precedence over the mesh-wide global policy. Istio resolves policy by specificity: namespace-scoped configuration overrides mesh-scoped, satisfying the requirement to supersede the global policy for all workloads in 'default'.

Setting `consecutive5xx: 5` instructs the sidecar's outlier detector to eject a host after five successive 5xx responses, directly matching the stem's threshold. Other consecutive-error counters, such as `consecutiveGatewayErrors`, track different status classes and would not trigger on generic 5xx failures.

`istioctl proxy-config all` dumps every Envoy configuration category — clusters, listeners, routes, endpoints and secrets — for the named pod's sidecar, satisfying the requirement to inspect the full envoy config. Unlike narrower subcommands such as `cluster` or `listener`, `all` returns the complete configuration in one pass.

Canary deployment is a traffic management pattern that shifts a small percentage of live traffic to a new version, then gradually increases it. This progressive rollout limits blast radius, matching the question's requirement for a recognised traffic management pattern.

baseEjectionTime sets the duration a pod stays ejected from the load-balancing pool before being returned for health re-evaluation. This directly satisfies the stem's requirement: it is the field governing how long an ejected pod remains out of rotation, measured from the moment of ejection.

VirtualService defines how requests are routed to a service within Istio's traffic management API, specifying matching rules and destinations. It is a core traffic management component, satisfying the question's requirement for valid Istio traffic management resources.

The Kubernetes Gateway resource models Layer 4 and Layer 7 routing, so listeners can be configured for HTTP, HTTPS, GRPC and TCP traffic. This protocol set satisfies the requirement to expose both web and raw TCP services through one gateway.

The `spec.components` section of IstioOperator exposes per-component configuration for core control plane deployments. Pilot, the traffic management component now named istiod, is configured here through fields such as `pilot.k8s` and `pilot.env`, satisfying the stem's requirement for components settable via that section.

A gateway consolidates access to several backend services behind one address, giving clients a single, unified entry point rather than separate endpoints. It satisfies the stem's requirement for one entry point by routing and translating requests to the appropriate service, unlike a proxy that typically forwards to a single destination.

Installing the new control plane as a separate revision lets both versions run side by side, so workloads stay on the old revision until explicitly migrated. This coexistence is the foundation of canary upgrades, enabling gradual, reversible rollout rather than an all-at-once replacement.

RequestAuthentication only validates JWTs if present, but it does not reject requests without a JWT. To enforce that a valid JWT is required, you must create an AuthorizationPolicy that allows only requests with a validated JWT. This is typically done by matching on the 'requestPrincipals' field, which is populated after successful JWT validation. Without this policy, requests without a JWT would still be allowed, so this step is necessary to block them.

DestinationRule outlierDetection continuously ejects pods that return consecutive 5xx errors or fail health checks, removing them from the load-balancing pool so traffic reaches only healthy endpoints. This directly satisfies the stem's requirement to route traffic exclusively to healthy pods, unlike liveness probes, which merely restart containers without influencing routing decisions.

Header-based matching is expressed inside the match block of an HTTP route, using a headers list with exact, prefix or regex matchers. This satisfies routing decisions based on request headers rather than URI or method alone.

RequestAuthentication supports a workloadSelector, so the JWT validation rules it defines apply only to the pods matching that selector rather than the whole namespace. This satisfies the requirement of scoping authentication policy to specific workloads.

The http routes block is mandatory: it defines the match conditions and destination subsets that split traffic between stable and canary versions. Without it, the VirtualService has no routing rules to weight, so canary splitting cannot occur.

maxEjectionPercent defines the maximum percentage of endpoints in the load-balancing pool that can be ejected simultaneously. Setting it to a value like 40 ensures that even if many hosts fail, at least 60% remain available to serve traffic. This directly controls how many hosts can be ejected, which is one of the two requirements in the scenario.

RequestAuthentication validates JWTs presented by clients. The jwksUri points to the JSON Web Key Set endpoint holding the public keys; Envoy fetches these keys to verify each token's signature, ensuring the JWT was issued by the trusted identity provider.

Each entry in the listeners block must specify the port the listener binds to on the Gateway, alongside its protocol. This port determines which traffic the listener accepts, satisfying the requirement that listeners define the network endpoint for incoming connections.

Weight assigns a relative proportion of traffic to each destination within a single route block, letting you split requests across multiple subsets or hosts. This satisfies the stem's requirement by distributing load between several destinations rather than sending all traffic to one.

Kiali renders red edges when the destination workload reports elevated error responses or when an Istio authorisation or traffic policy rejects requests. This colouring reflects the measured error rate on that edge, not latency or throughput, so it points to failures or policy blocks.

DestinationRule defines connection pool limits under its trafficPolicy, using tcp.maxConnections to cap concurrent TCP connections to a service. This directly satisfies the stem's requirement to limit total concurrent connections, since the setting is enforced per destination host by Envoy sidecars.

The analyze sub-command inspects a live cluster or configuration files for misconfigurations, reporting warnings and errors. It validates Istio resources against best practise, making it a genuine istioctl sub-command used for diagnosing broken mesh configuration.

Envoy evaluates the response against the retryOn condition, comparing the returned status code or reset type to the configured list. Only matching failures trigger the retry budget, so non-matching errors pass straight back to the caller.

The `attempts` parameter sets how many times Envoy re-tries a failed request before returning an error to the caller, satisfying the stem's requirement for configurable retry-policy parameters. Istio's VirtualService retry block exposes `attempts` alongside `perTryTimeout` and `retryOn`, so it is directly configurable.

Connection pool limits and circuit breaker thresholds for a service are configured in the DestinationRule under trafficPolicy.connectionPool. The tcp and http subsections define maximum connections and pending requests respectively. This is the correct location because DestinationRules define policies that apply after routing, including connection-level controls for the selected service.

Setting PeerAuthentication's mtls.mode to STRICT in the prod namespace enforces namespace-wide mTLS, rejecting any plaintext or permissive traffic to workloads there. This satisfies the requirement that all workloads accept only mTLS, without per-pod configuration, since STRICT overrides mesh-level defaults for that namespace.

The operation field lists the HTTP methods and exact paths a rule matches, such as GET on /products. It defines the request attributes the policy evaluates, letting you scope authorisation to specific endpoints rather than whole workloads.

Gateway references in a VirtualService are resolved as '<namespace>/<name>' when the Gateway lives in a different namespace than the VirtualService. Because payments-vs is in 'prod' and payments-gw is in 'istio-system', the short name only resolves within the VirtualService's own namespace, so the Gateway never binds the route and clients receive 404. Qualifying the reference with the Gateway's namespace binds the route correctly.

A VirtualService allows you to define HTTP routes that match on request attributes such as headers, and then route to different destinations with weights. You can create a route that matches a specific header (e.g., user: test) and directs to the new version, and another route with a weight-based split (90/10) for all other traffic. This achieves both the canary rollout and the sticky routing for the test user.

Istio infers the protocol for a Service port from the port name prefix (http-, tcp-, grpc-, etc.), so naming 8080 http-api and 9090 tcp-admin makes the sidecar apply HTTP parsing to one and opaque TCP handling to the other. This is the standard, supported way to declare per-port protocol on a Kubernetes Service without extra configuration.

The Envoy sidecar retrieves the JSON Web Key Set directly from the URL declared in the RequestAuthentication resource's jwksUri field, caching the keys locally. This satisfies the verification requirement because the sidecar validates JWT signatures itself without routing token checks through an external service.

Istio's outlier detection ejects a host once its consecutive 5xx responses reach the value set in consecutive5xxErrors, counted per host over the interval. This field directly governs the ejection threshold, unlike interval or baseEjectionTime, which control timing rather than the error count.

"Servers" is a valid Gateway configuration because Istio's ingress gateway can run directly on bare-metal or virtual machines, not only as a Kubernetes pod. This satisfies the stem's requirement for valid deployment targets, since the gateway workload may be hosted on standalone servers outside a cluster.

consistentHash hashes a chosen request attribute, such as a cookie or source IP, so the same user consistently maps to the same pod, satisfying the requirement that requests from one user always reach the same pod.

PeerAuthentication in Istio's security API defines the mTLS mode (STRICT, PERMISSIVE, DISABLE) that the mesh enforces for a workload or namespace. Without it, sidecars default to PERMISSIVE, so plaintext remains accepted and mutual authentication is never guaranteed.

Acts as the CA.

STRICT mode enforces mutual TLS, so plaintext or non-mTLS client connections to the workload are refused at the sidecar proxy. This directly satisfies the scenario's requirement that requests without mTLS be rejected, confirming the PeerAuthentication policy is active and enforcing rather than merely permissive.

A VirtualService defines the routing rules that distribute requests across versioned workloads, satisfying the requirement to split traffic between versions. It matches on hosts, paths and headers, then weights destinations to specific subsets, so percentage-based canary or blue-green distribution becomes possible when paired with a DestinationRule.

Updating the `istio.io/rev` label to `1-19` and restarting pods triggers sidecar injection from the new revision's mutating webhook, satisfying the requirement to migrate the namespace between revisions. Existing pods retain their old sidecar until restarted, so the restart is essential to complete the move.

The timeout field in the VirtualService's HTTP route specifies how long a request may run before Istio aborts it, so setting it to 2s enforces the required limit on the orders service. Other fields control retries, faults or matching, not request duration.

Outlier detection actively ejects endpoints that return consecutive errors from the load balancing pool for a defined interval, then returns them for re-evaluation. This satisfies the stem's requirement by isolating unhealthy hosts, preventing failed requests from reaching them while other healthy endpoints continue serving traffic.

Without a sidecar proxy, there is no Envoy instance to enforce Istio's authorization rules, so the policy has no effect on traffic. Istio's control plane distributes policy to sidecars, not to the application itself; absent that enforcement point, requests proceed unauthenticated and unrestricted.

The Telemetry API is the supported, declarative way to configure metrics, access logging, and tracing for workloads in a mesh. It supports defining providers, including OpenTelemetry, and selecting which workloads emit which signals. Because it is applied through Istio configuration rather than application changes, it meets the goal of exporting telemetry to a central platform without touching the app or redeploying it.

istioctl proxy-config routes queries the Envoy admin API and prints the route configuration currently loaded in a specific sidecar. This satisfies the constraint of verifying actual routes, revealing whether the VirtualService changes were pushed and how they were translated.

VirtualService supports fault injection, including a fixed delay applied to matching requests. Specifying a five-second delay in the http fault block makes Envoy hold each matching request, satisfying the testing requirement without changing application code.

An ALLOW policy with a source.principals match permits only requests whose peer certificate carries the SPIFFE ID cluster.local/ns/payments/sa/payment-processor. Because Istio's default is to deny when any ALLOW policy exists for the workload, all other identities are implicitly rejected. This exactly implements least-privilege, identity-based access in a STRICT mTLS mesh.

Envoy sidecar proxies are deployed alongside each service instance and intercept all inbound and outbound traffic. They generate a rich set of metrics, including request counts, response codes (like 5xx), and latency. These metrics are exposed on the sidecar's Prometheus endpoint and scraped by Prometheus. Therefore, the sidecar is directly responsible for generating the 5xx error metrics for a service.

The `trafficPolicy` block accepts `loadBalancer`, which configures how Istio distributes requests across a service's endpoints — for example `ROUND_ROBIN`, `LEAST_REQUEST` or `RANDOM`. This satisfies the stem's requirement for a genuine trafficPolicy field, since load balancing policy is defined there rather than in the DestinationRule's top-level spec.

The Gateway resource's servers block declares the hosts, port and TLS settings the ingress or egress proxy listens on. This satisfies the stem directly: host definitions belong to the Gateway, while routing rules referencing that gateway live in the VirtualService.

Istio's VirtualService defines routing rules, including weighted destination subsets, so you can direct a percentage of traffic to the canary version and the remainder to the stable one. DestinationRule merely defines those subsets; the VirtualService performs the actual traffic split.

An ALLOW action paired with an empty rule set matches every request unconditionally, because no conditions restrict which traffic qualifies. This differs from ALLOW with populated rules, which permits only requests satisfying those specific conditions, and from DENY, which blocks matching traffic.

The subset's label selector lives in the DestinationRule spec, under subsets[].labels. If those labels do not match the pod labels, no endpoints populate the subset and traffic fails, so that is where the match must be verified.

Listing the PeerAuthentication custom resources across all namespaces queries the live mesh configuration directly, so it reveals every policy currently enforced. The -A flag satisfies the requirement to show policies mesh-wide rather than only those in the current namespace.

VirtualService HTTP route match rules support URI path conditions, directing requests to distinct destinations based on the URL path. This path-based routing capability is exactly what the scenario requires, unlike DestinationRule, which handles subsets and policies after routing is decided.

istioctl proxy-config reads the sidecar's live Envoy configuration directly from the proxy, showing clusters, listeners, routes and endpoints. It satisfies the constraint of verifying pushed configuration without Kiali, querying the data plane rather than relying on the dashboard.

PeerAuthentication enforces mutual TLS between workloads in the Istio mesh, satisfying the requirement for an mTLS policy resource. Its mtls mode setting (STRICT, PERMISSIVE or DISABLE) controls whether sidecar proxies accept only encrypted, certificate-authenticated connections, directly configuring transport-level authentication rather than authorisation or routing.

PeerAuthentication defines the mutual TLS mode Istio applies to workloads in a namespace or mesh, satisfying the requirement to control service-to-service encryption. Its mtls.mode field accepts STRICT, PERMISSIVE or DISABLE, governing whether sidecars accept plaintext alongside encrypted traffic. This makes it the resource for configuring workload mTLS behaviour.

MeshConfig sets mesh-wide defaults for Envoy proxies, covering access logging, tracing, and traffic policy such as mutual TLS and outbound traffic handling. It satisfies the requirement for cluster-wide behaviour rather than per-workload settings, which belong in sidecar or destination rule resources.

The match field within an HTTP route accepts header criteria, letting you specify exact, prefix or regex matches on a named header. This satisfies the stem's requirement for defining custom header matching in a VirtualService.

root-cert.pem holds the trusted root CA certificate that both workloads and the Istio control plane use to validate peer certificates, anchoring the mTLS trust chain. This satisfies the stem's constraint by providing the common trust anchor for certificate verification.

Outlier detection ejects the host for baseEjectionTime once consecutive 5xx errors reach the threshold within the interval. Five errors in one second triggers ejection, so the host is removed from the load-balancing pool for 30 seconds.

The fault field injects delays or aborts into a percentage of requests at the Envoy proxy, directly satisfying the resilience-testing requirement without touching application code. Other VirtualService fields handle routing, retries and mirroring, but only fault deliberately corrupts traffic.

A VirtualService match inspects HTTP headers directly, so an exact or regex match on `x-user-type` routes requests to the appropriate destination. This satisfies the stem's requirement to route by that header, unlike host- or path-based rules, which cannot discriminate on arbitrary request headers.

A ServiceEntry adds the external dependency to Istio's internal service registry, giving mesh sidecars the DNS name, endpoints and ports needed to route traffic to it. This directly satisfies the stem's constraint: the dependency is absent from the Kubernetes registry, so mesh services cannot otherwise resolve or reach it.