Istio Certified Associate (ICA, CNCF/Linux Foundation) (ICA) ICA Questions 226–234 | Page 4/4

226

MCQeasy

Can you configure fault injection for specific traffic patterns, such as user headers?

A.No, fault injection is global for the service.

B.No, it must be applied via global EnvoyFilter.

C.Yes, by adding a 'match' criteria in the VirtualService.

D.Yes, but only via DestinationRule.

E.Yes, but only for egress traffic.

AnswerC

VirtualService fault injection supports a match block, so you can scope the abort or delay to requests carrying specific headers such as a user identifier. Without match, the fault applies to all traffic to that host.

Why this answer

Yes, fault injection can be scoped to specific route matches in a VirtualService.

Full explanation →

227

MCQhard

When using JWT, what is the 'forwardOriginalToken' flag in the RequestAuthentication resource?

A.It deletes the token from the request.

B.It forwards the token to the application.

C.It encrypts the token.

D.It logs the token to the audit log.

AnswerB

forwardOriginalToken preserves the original JWT and passes it unchanged to the backend application after RequestAuthentication validates it. This satisfies scenarios where the workload itself must read the token, rather than relying solely on Istio's validation.

Why this answer

When set to true, the proxy forwards the original JWT to the application, allowing the application to use the token for backend calls.

Full explanation →

228

MCQeasy

Which command is used to view the effective configuration of a specific Envoy proxy?

A.istioctl dashboard

B.istioctl proxy-config

C.kubectl get virtualservice

D.kubectl describe

AnswerB

`istioctl proxy-config` queries a specific Envoy's live xDS state, dumping listeners, clusters, routes and endpoints as actually applied. This satisfies the stem's requirement for the effective configuration of one named proxy, rather than the mesh-wide desired state that `istioctl analyze` or the IstioOperator spec would show.

Why this answer

istioctl proxy-config is the standard tool for inspecting sidecar config.

Full explanation →

229

MCQmedium

When migrating to the Kubernetes Gateway API in Istio, you define a Gateway resource. Which component is responsible for translating this Gateway resource into Envoy configuration?

A.istiod

B.The Kiali operator

C.The Envoy proxy sidecar

D.The ingress-gateway deployment

AnswerA

Istiod acts as the control plane's configuration translator: it watches Gateway resources, merges them with VirtualService routing, and pushes the resulting Envoy listener, route and cluster configuration to the sidecars and ingress gateways via xDS. Without istiod, the Gateway spec would never become proxy config.

Why this answer

istiod is the Istio control plane component that watches Gateway API resources (Gateway and HTTPRoute) and translates them into Envoy xDS configuration pushed to the gateway proxy pods. When you define a Gateway resource, istiod's config controller reconciles it and generates the corresponding listener, route, cluster, and endpoint configuration for the Envoy data plane.

Exam trap

The trap here is confusing the data plane (Envoy gateway pod) with the control plane (istiod) — candidates often assume the gateway pod reads the Gateway resource directly, when in fact istiod performs all translation and pushes xDS config.

How to eliminate wrong answers

Option B is wrong because the Kiali operator only manages the Kiali observability console deployment and its configuration — it does not translate Gateway resources into Envoy config. Option C is wrong because the Envoy sidecar is a per-workload data plane proxy that receives xDS config from istiod; it does not perform translation of Gateway resources itself. Option D is wrong because the ingress-gateway deployment is simply the pod running Envoy that receives configuration — it is a consumer of the translated config, not the translator.

Full explanation →

230

Multi-Selectmedium

Which TWO of the following are valid fault injection types in Istio?

Select 2 answers

A.retry

B.timeout

C.redirect

D.delay

E.abort

AnswersD, E

Delay injects a fixed latency into matching requests before they reach the target, using the HTTPFaultInjection delay field with a specified duration. This satisfies the stem's requirement for a valid Istio fault injection type, since Istio supports both delay and abort faults, letting you simulate slow upstream services without altering application code.

Why this answer

Istio natively supports abort (returning an error) and delay (simulating latency).

Full explanation →

231

MCQmedium

Your team needs to allow end-users to authenticate using JWT tokens issued by an external OIDC provider. Which resource should you define to validate these tokens?

A.AuthorizationPolicy

B.ServiceEntry

C.PeerAuthentication

D.RequestAuthentication

AnswerD

RequestAuthentication defines the JWT issuer, JWKS endpoint and validation rules that Istio uses to verify tokens from an external OIDC provider, rejecting requests with invalid tokens. It satisfies the stem's requirement to validate externally issued JWTs at the mesh.

Why this answer

RequestAuthentication is specifically designed to configure how Istio validates JWT tokens.

Full explanation →

232

Multi-Selecthard

Which THREE settings are part of the 'connectionPool' configuration in a DestinationRule?

Select 3 answers

A.http

B.http2

C.grpc

D.tls

E.tcp

AnswersA, B, E

The `http` field configures HTTP-specific connection pool limits, namely `http1MaxPendingRequests`, `http2MaxRequests` and `maxRequestsPerConnection`, which govern request-level queuing and reuse. This satisfies the stem's requirement for a `connectionPool` setting, as distinct from TCP-level limits such as `maxConnections` and `connectTimeout`.

Why this answer

In an Istio DestinationRule, the connectionPool field is a TrafficPolicy-level setting that contains three protocol-specific sub-fields: tcp, http, and http2. Option A (http) is correct because connectionPool.http configures HTTP/1.1 connection pool limits such as http1MaxPendingRequests, http1MaxRequestsPerConnection, maxRequestsPerConnection, and idleTimeout. Option B (http2) is correct because connectionPool.http2 configures HTTP/2-specific limits such as maxRequestsPerConnection and idleTimeout for HTTP/2 traffic.

Option E (tcp) is correct because connectionPool.tcp configures TCP-level settings including maxConnections, connectTimeout, and tcpKeepalive. Option C (grpc) is not a connectionPool sub-field; gRPC traffic is governed through the http2 pool settings. Option D (tls) is not part of connectionPool; TLS-related settings in a DestinationRule live under trafficPolicy.tls (e.g., mode, clientCertificate) or under the port-level tls block.

Full explanation →

233

MCQhard

To test the resilience of your microservice architecture, you want to introduce a 5-second delay to 50% of the requests directed to the 'catalog-service'. Where do you define this configuration?

A.DestinationRule

B.VirtualService

C.Gateway

D.ServiceEntry

AnswerB

Istio applies traffic-shaping rules such as fault injection through VirtualService, which supports an HTTP fault with a fixed delay and a percentage match on the catalog-service host. DestinationRule handles load balancing and connection pools, not request delays.

Why this answer

A VirtualService is used to define traffic routing rules, including fault injection such as delays and aborts. To introduce a 5-second delay to 50% of requests to 'catalog-service', you configure a fault delay in the VirtualService's HTTP route. This allows testing resilience without modifying the application.

Exam trap

ICA often tests the confusion between VirtualService and DestinationRule, leading candidates to pick DestinationRule for fault injection.

How to eliminate wrong answers

Option A is wrong because DestinationRule defines policies for traffic after routing, such as load balancing, connection pool, and outlier detection, but not fault injection. Option C is wrong because Gateway configures ingress/egress traffic at the edge, not internal service-to-service fault injection. Option D is wrong because ServiceEntry adds external services to the mesh, not for fault injection.

Full explanation →

234

MCQhard

You configure a VirtualService for the 'payments' service with an HTTP route that applies a retry policy of 3 attempts with a 2s perTryTimeout, and a global timeout of 5s. During peak load, callers report that requests fail after roughly 5 seconds even though some retries were still in flight. Which behavior of the global timeout explains this?

A.The global timeout is the total time budget for the entire request including all retry attempts; once it elapses, the request fails regardless of remaining retries.

B.The global timeout only applies to websocket and streaming routes; for standard HTTP it is overridden by perTryTimeout, so 5s is irrelevant.

C.The global timeout is ignored whenever a retry policy is present, so the 5s failures must come from the application itself.

D.The global timeout applies only to the first attempt, and subsequent retries each get a fresh 5s budget, so failures at 5s are coincidental.

AnswerA

Istio's HTTPRoute timeout defines the overall deadline for the request as a whole, encompassing all retries. If the 5s global timeout expires while retries are still pending, Envoy terminates the request and returns a timeout to the caller. This is exactly why callers see failures near 5 seconds even when individual retries had not yet been exhausted, since the aggregate budget was consumed.

Why this answer

The route-level timeout is the overall deadline for the request, covering all attempts and retries. When it expires, Envoy ends the request even if retries remain, so a 5s timeout produces failures near 5s. perTryTimeout only limits each individual attempt, so it cannot extend the total budget beyond the global timeout. The observed timing matches the aggregate deadline.

Exam trap

The trap here is assuming the global timeout resets for each retry attempt rather than acting as a single overall deadline for the entire request.

Full explanation →

Istio Certified Associate (ICA, CNCF/Linux Foundation) (ICA) (ICA) — Questions 226–234