Istio Certified Associate (ICA, CNCF/Linux Foundation) (ICA) (ICA) — Questions 151–225

kubectl get pods lists every pod in the namespace, and because each sidecar-injected pod appears as a single pod with its proxy container, this command shows all pods including proxies. It satisfies the stem's requirement to view status across pods and their injected proxies.

ServiceEntry adds external endpoints to Istio's internal registry, letting sidecars route to a service outside the mesh. It satisfies the stem's constraint of defining a local service absent from the cluster: the entry registers the hostname, address and ports, so Envoy treats the external destination as mesh-local.

REDIRECT is an Envoy route action, not an authorization decision, so it cannot appear in an Istio AuthorizationPolicy. The policy's action field accepts only ALLOW, DENY, and CUSTOM, which satisfies the stem's requirement for an invalid action.

http1MaxPendingRequests caps how many HTTP/1.1 requests may queue awaiting a connection, directly satisfying the requirement to limit pending requests. Istio's circuit breaker uses this field to shed load once the threshold is exceeded, returning overflow failures rather than allowing unbounded queueing.

Weighted routing in a VirtualService http.route block splits traffic across destinations by percentage, and the weights must sum to 100. Setting 90 and 10 sends nine-tenths to stable and one-tenth to the canary, exactly matching the requested canary split. This is the canonical Istio pattern for progressive delivery and integrates with the named subsets from the DestinationRule.

The VirtualService destination block uses the subset field to name a subset declared in the corresponding DestinationRule, restricting routing to those labelled pods. This satisfies the constraint of limiting traffic to a specific subset rather than the whole service.

PERMISSIVE mode allows the workload to accept both mTLS and plaintext traffic. This satisfies the requirement to enforce mTLS for mesh services while still allowing the legacy service to connect without mTLS. The selector ensures the policy applies only to the 'database' workload. This is the correct configuration for a gradual migration to strict mTLS or for accommodating non-mesh clients.

`istioctl verify-install` validates an existing Istio installation by comparing deployed resources against the manifest, reporting missing or misconfigured components. It directly satisfies the stem's requirement to verify control plane deployment status, confirming that istiod and related resources are present and healthy rather than merely previewing configuration.

The `interval` setting defines how frequently the outlier detection engine evaluates each backend, expressed as a duration. It satisfies the stem's requirement for a setting configured inside the `outlierDetection` block, controlling the evaluation cadence that determines when unhealthy hosts are ejected from the load-balancing pool.

In ambient mode without sidecars, mTLS and authorisation are handled by the node-level ztunnel proxy rather than per-pod Envoy sidecars. PeerAuthentication policies are therefore enforced by the ztunnel, which terminates and originates the workload traffic on behalf of each pod.

The mirror field in a VirtualService duplicates live traffic to a shadow destination while the primary response is returned to the caller. This satisfies traffic shadowing, letting you test a new version with real requests without affecting production responses.

The redirect field in an HTTP route rewrites the request to a different URI or authority, returning a 301 by default. This satisfies the stem's path-redirection requirement, unlike rewrite, which forwards to the destination while altering the path.

The weight field under an HTTP route destination splits traffic proportionally between subsets, so assigning unequal weights (for example 90/10) sends a controlled share to a canary version. This satisfies the A/B testing requirement by enabling gradual, measurable traffic distribution across versions.

PeerAuthentication is the mesh-wide resource governing how sidecars receive and require mTLS. Applying one in the root namespace without a selector sets the mesh-wide default to STRICT, enforcing mutual TLS for every workload in the cluster.

A ServiceEntry registers the external host in the mesh registry, while a VirtualService routes matching traffic to the egress gateway. Together they satisfy the requirement that all outbound traffic to that external service passes through the EgressGateway.

In `outlierDetection`, `interval` sets how often Envoy scans each host's ejection status, satisfying the requirement for a timing parameter governing consecutive failure evaluation. It works alongside `consecutiveErrors` and `baseEjectionTime`; without it, ejection checks would lack a defined polling cadence, so it belongs among the three valid settings.

The clusters subcommand lists the upstream clusters Envoy knows about, showing the services and subsets the proxy can route to. This reveals the proxy's configured backends, which is one of the three information types requested.

Downloading the istioctl binary directly from the Istio release page places the CLI on the local machine, which is the documented standard installation method. Package managers and Helm charts install the control plane, not the istioctl client tool itself.

Labelling the namespace with `istio-injection=enabled` triggers Istio's mutating admission webhook, which automatically injects the sidecar proxy into every pod created there. This satisfies the stem's constraint of enabling injection without editing deployment manifests, since the injection happens at pod admission rather than in the workload definition.

DestinationRule is where trafficPolicy defines connectionPool limits and outlierDetection for a destination. To confirm what the proxy actually enforces, istioctl proxy-config cluster shows the Envoy cluster's circuit breaker and outlier detection fields derived from that resource. This combination directly answers which settings are active and is the standard diagnostic path for suspected breaker trips.

RequestAuthentication validates the JWT signature by fetching signing keys from the issuer's JWKS URI. If the proxy cannot reach that endpoint, key retrieval fails and signature verification cannot complete, so the token is rejected even though the issuer claim itself is correct.

`perTryTimeout` caps the duration of each individual retry attempt, satisfying the stem's requirement for a single-attempt limit. It differs from `timeout`, which bounds the entire request lifecycle including all retries. Setting `perTryTimeout` ensures a slow attempt is abandoned before consuming the overall VirtualService deadline.

With no AuthorizationPolicy bound to a workload, Istio's default posture is permissive: requests reaching the sidecar are forwarded without authorisation checks. This satisfies the stem's "no policy present" constraint, since enforcement only activates once a policy selects the workload. Traffic is therefore allowed by default.

The label istio.io/rev=1-21-0 instructs the sidecar injector to use the control plane revision named 1-21-0 for pods in the payments namespace. This is the documented mechanism for revision-based injection and works alongside MutatingWebhookConfiguration entries that the injector creates for each revision. It allows simultaneous revisions in the same cluster without affecting other namespaces.

Gateway configures a standalone Envoy at the mesh edge, opening the listener ports and hosts that admit external traffic. This satisfies the constraint of defining the entry point, since inbound requests must match the Gateway's servers before a VirtualService can bind and route them.

Shorter interval = faster checks.

`istioctl analyze` inspects live cluster configuration and reports misconfigurations, such as conflicting virtual services or missing sidecars, that degrade mesh health. It satisfies the debugging constraint by surfacing actionable diagnostics without requiring traffic capture, unlike proxy-level tools such as `istioctl proxy-config`.

Envoy sidecars and gateways intercept every request and apply the pushed listener, route and filter rules, including mTLS and authorization checks. This satisfies the constraint because policy enforcement occurs at the proxy, not in istiod, which only distributes configuration.

STRICT mode rejects plaintext traffic, so every workload in the namespace must present a sidecar-managed certificate. A legacy service without an injected sidecar cannot complete the mTLS handshake, since no Envoy proxy terminates TLS on its behalf. The namespace-wide policy therefore blocks it, satisfying the stem's encryption constraint.

The subset field selects a named subset of a destination's endpoints, defined by labels such as version, so traffic routes only to pods matching that label set. This enables version-specific or canary routing within Istio VirtualService destinations.

DestinationRule defines named subsets by matching pod labels, so header-based routing in the VirtualService can reference a specific version. The subset itself lives in the DestinationRule; the VirtualService only selects it, satisfying the requirement to route by header to one version.

DestinationRule defines traffic policies for a service, including outlier detection, which ejects unhealthy hosts and implements circuit breaking. This satisfies the requirement to prevent cascading failures during high latency by limiting traffic to failing endpoints, unlike VirtualService, which handles routing rules rather than health-based ejection.

The 'when' field in an authorization policy accepts conditions evaluated against request attributes, and 'request.headers' exposes individual header values for matching. This lets you permit or deny traffic only when the named header is present, satisfying the requirement to restrict access based on a specific request header.

Configuring the timeout field enforces the 2-second limit, causing the request to fail immediately once that duration elapses. This directly satisfies the stem's constraint of aborting slow or hanging requests rather than letting them continue indefinitely, which is exactly the behaviour required for the occasionally hanging service.

Egress Gateways can handle mTLS termination/origination for external traffic.

Without a VirtualService, Istio's sidecar proxies fall back to Envoy's native load-balancing across all endpoints discovered for the service, defaulting to round-robin distribution. No layer-7 traffic rules are applied, so routing remains at layer 4 with equal weighting per healthy endpoint, satisfying the scenario's absence of any defined VirtualService.

Istio splits traffic through VirtualService routing rules, where weighted destinations distribute percentages across subsets. Configuring a 90/10 weight split in the VirtualService's HTTP route satisfies the requirement to send 10% of traffic to the new version.

The Gateway defines the ingress listener on port 443 with TLS termination via tls.mode SIMPLE and a referenced certificate secret, while the VirtualService binds to that Gateway using the gateways field and routes to the internal service on port 80. This is the standard ingress pattern for terminating TLS at the gateway. Both resources are required and must reference each other correctly.

RequestAuthentication validates the JWT against the specified issuer, while AuthorizationPolicy enforces that only requests carrying a token from that issuer are permitted. Together they satisfy the constraint of restricting the service to a single trusted JWT issuer.

An AuthorizationPolicy without an action field defaults to ALLOW, satisfying the stem's constraint that no explicit action is declared. Istio's authorisation engine treats the absence of an action as permissive, so matching requests pass through. This differs from DENY, which requires explicit specification, making ALLOW the implicit baseline behaviour.

connectionPool is a valid trafficPolicy field, defining TCP connection limits such as maxConnections, connectTimeout and HTTP limits for the destination. It controls how Envoy manages upstream connections, making it a legitimate setting within a DestinationRule's traffic policy.

Increasing the interval makes the detector scan less frequently, reducing the likelihood of premature ejection.

istiod is the control plane's unified binary; it runs the Pilot component, which watches Kubernetes services and Istio configuration, then generates and pushes the xDS configuration (CDS, EDS, LDS, RDS) to Envoy sidecars. No other component performs this translation.

The minimal profile installs only istiod, the ingress gateway and the istio-cni component, omitting telemetry add-ons such as Prometheus, Grafana and Jaeger. This directly satisfies the requirement to disable unnecessary features and conserve cluster resources in the development environment.

The proxy-config cluster command with the -o json flag outputs the full cluster configuration in JSON format. This includes the outlier detection settings, which are part of the cluster's configuration. By examining the JSON output, you can verify the exact outlier detection parameters applied to the cluster, such as consecutive errors, interval, and ejection percentages. This is the most direct way to inspect those settings.

DestinationRule defines traffic policies for a service, including connection pool limits and outlier detection, which ejects unhealthy hosts to achieve circuit breaking. This satisfies the stem's requirement for the resource that configures circuit breaking, as opposed to routing (VirtualService) or gateway configuration.

Retry policies are configured in the VirtualService's HTTP route, where the retries block specifies attempts, perTryTimeout and retryOn conditions. This satisfies automatic retrying of failed requests, including 503 responses, before returning an error to the caller.

Locality-aware load balancing prioritises endpoints within the same zone or region, so requests avoid crossing availability-zone boundaries. This directly reduces round-trip latency and cuts cross-zone egress charges, satisfying the stem's requirement for the main advantage over default round-robin distribution across all healthy endpoints.

VirtualService HTTP route rules carry a timeout field that caps the total duration of a request to the destination, so setting it to 5s enforces the limit. DestinationRule governs connection pooling and outlier detection, not request timeouts.

The subsets field in a DestinationRule groups endpoints by label, typically the version label, enabling traffic policies and routing to target distinct service versions. It satisfies the versioning requirement because VirtualService routing rules reference these named subsets to split traffic.

`istioctl analyze` performs static analysis of Istio configuration, checking YAML resources and live cluster state against known validation rules. It surfaces misconfigurations such as conflicting virtual services, missing gateways, or invalid selectors before they cause runtime failures, satisfying the need to identify configuration issues proactively rather than debugging symptoms after deployment.

ROUND_ROBIN is Istio's default load balancing algorithm, distributing requests sequentially across healthy endpoints in each locality. This satisfies the stem's constraint of identifying the out-of-the-box behaviour, requiring no DestinationRule traffic policy override. Other algorithms such as LEAST_REQUEST, RANDOM and PASSTHROUGH demand explicit configuration.

connectionPool sits within DestinationRule trafficPolicy and defines TCP or HTTP connection limits to an upstream service, including maxConnections, http1MaxPendingRequests and http2MaxRequests. It satisfies the question by being one of the traffic policy fields governing how connections are managed.

istioctl proxy-config secret <pod-name> queries the Envoy instance's secret configuration, showing the SDS-delivered certificate, its validity and the CA chain used for mTLS. This satisfies the stem's constraint by confirming the pod holds an active mTLS certificate.

A PeerAuthentication with mode PERMISSIVE and a workload selector overrides the namespace-wide STRICT policy for that specific workload only, allowing plaintext alongside mTLS. The legacy service, unable to present certificates, can then communicate while the rest of the namespace remains strict.

When the outlier detection thresholds are breached, the circuit breaker ejects the unhealthy endpoint from the load-balancing pool. Envoy then stops routing new requests to that instance, giving it time to recover while traffic flows to remaining healthy endpoints.

Envoy sidecar proxies enforce circuit breaking and fault injection at the data plane, applying the outlier detection and abort or delay rules configured in Istio resources. Istiod only distributes configuration; the actual traffic manipulation happens inside Envoy.

RequestAuthentication supports an array of jwtRules, and each rule can define a distinct issuer and jwksUri. Istio will attempt to validate an incoming JWT against all configured rules, accepting the token if it matches any rule. This is the correct way to support multiple issuers with different key sets.

DestinationRule defines traffic policy for a service after routing, and its connectionPool block specifies TCP and HTTP limits such as maxConnections and http1MaxPendingRequests. This satisfies the stem's requirement to configure connection pool settings per service, unlike VirtualService, which handles routing rules rather than pool limits.

VirtualService resources in Istio route traffic by matching request attributes and splitting weights across destination subsets, enabling controlled traffic shifting between two service versions. This satisfies the stem's requirement for gradual, percentage-based canary rollouts without redeploying workloads.

PeerAuthentication enforces mutual TLS between sidecars, encrypting all service-to-service traffic inside the mesh. This directly satisfies the stem's requirement for securing intra-mesh traffic, since Istio's data plane authenticates both ends of every connection using workload identities issued by the mesh's certificate authority.

maxEjectionPercent caps the share of endpoints that may be ejected from a load-balancing pool. Setting it to 0 permits no endpoints to be removed, so outlier detection effectively stops ejecting hosts and the feature is disabled.

The 'when' condition with key request.auth.claims[custom-claim] matches the validated JWT claim against the listed values, so the policy allows or denies based on that claim. This satisfies the stem's constraint of authorising users via a custom JWT claim.

Kiali is the Istio console that renders the service mesh topology and traffic-management rules graphically, satisfying the stem's GUI visualisation requirement. It reads Istio configuration directly, showing virtual services, destination rules and their routing relationships.

To migrate a namespace to the new revision, you update the 'istio.io/rev' label to the new revision name and then restart the pods so they are re-injected with the new sidecar. This is the documented canary upgrade procedure. It ensures the new sidecar is used without disrupting the entire mesh at once.

ServiceEntry resources have an exportTo field that controls which namespaces can see them. By default, they are exported to all namespaces (exportTo: *), but if it is set to a specific namespace or '.', only that namespace can use it. If the client pod is in a different namespace and the ServiceEntry is not exported there, the sidecar will not have the necessary configuration to route and collect telemetry for that external service, resulting in no logs or metrics.

The Sidecar resource scopes a workload's proxy to a defined set of namespaces and services, limiting which registries and endpoints it receives. This directly satisfies the multi-tenancy constraint by preventing cross-namespace visibility, unlike PeerAuthentication or AuthorizationPolicy, which govern mTLS and access rather than discovery scope.

The `maxRequestsPerConnection` field caps how many requests may traverse a single HTTP/1.1 or HTTP/2 connection before Istio closes and reopens it. This satisfies the stem's circuit-breaking constraint by bounding per-connection request volume, forcing periodic connection recycling rather than limiting concurrent requests or retries.

Mirroring duplicates each live request and dispatches the copy to a shadow destination alongside the primary service. The primary response still returns to the caller, so the test service receives realistic production traffic without affecting users, enabling safe validation before promotion.

The redirect field in the VirtualService rewrites the request's URI and authority, sending traffic to a different destination than the original request. It satisfies the requirement to redirect traffic to a different URI without altering the client.

The selector field is mandatory because it defines which pods the Gateway's configuration applies to, using label matching. Without it, the Gateway resource cannot bind to any workload, so Istio rejects the manifest during validation.

A route to a service with no matching pods yields a 503 Service Unavailable, because Istio's Envoy sidecars have no healthy upstream endpoints to load-balance to. The VirtualService route resolves, but the destination host's endpoint list is empty, so requests fail at the data plane rather than returning 404.

'RequestAuthentication' defines how Istio validates credentials on incoming requests, specifying JWT issuers, JWKS endpoints and audiences that must be satisfied. This directly fulfils the stem's requirement for JWT validation, rejecting tokens failing signature or claim checks before authorisation policies such as 'AuthorizationPolicy' evaluate the request.

The Graph view decorates each node and edge with health indicators, colouring them red or orange when error rates or warning conditions appear. This satisfies the requirement to surface operational state, letting operators spot degraded services directly on the topology rather than correlating separate metric dashboards.

Locality-aware load balancing keeps requests within the same region or zone where possible, cutting cross-cluster latency and avoiding failure domains. This directly satisfies the stem's high-availability goal by reducing dependence on any single cluster's network path.