32 questions · Scenario topic · All types, answers revealed
When using Istio with Kubernetes Gateway API, which object handles traffic routing rules based on path prefixes?
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 using Kubernetes Gateway API with Istio, which resource acts as the entry point for incoming traffic?
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.
Why this answer
The Gateway resource defines the entry point, including listeners, ports, and protocols.
When configuring a multi-cluster mesh, what does a 'ServiceEntry' with 'location: MESH_EXTERNAL' signify?
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.
Why this answer
It tells Istio that the service is external to the mesh, but it should be treated as a first-class citizen for routing and policy purposes.
Which THREE configuration areas are essential for ensuring observability in a complex Istio mesh?
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.
Why this answer
MeshConfig telemetry settings (B) are essential because the mesh-wide MeshConfig controls how Envoy sidecars emit telemetry, including access logging, metrics, and tracing defaults that determine whether observability data is generated at all. Tracing sampling rate (D) is essential because it governs what fraction of requests are captured as distributed traces; without an appropriate sampling rate, you either lose visibility into request flows or overwhelm the tracing backend. Telemetry resource configuration (E) is essential because the Telemetry API resources define providers, metrics, access logging, and tracing behavior per workload or namespace, directly shaping the observability signals collected across the mesh.
Local sidecar memory limits (A) affect resource consumption and stability but do not determine what telemetry is produced or exported, and VirtualService timeouts (C) are traffic-management controls for request deadlines, not observability configuration.
You are running an Istio mesh in a single Kubernetes cluster and have enabled sidecar injection in the 'payments' namespace. A client pod in that namespace cannot reach an external HTTPS API at api.example.com because the sidecar intercepts all outbound traffic and rejects it. You must allow only that host while keeping traffic to all other unknown external hosts blocked. What should you configure?
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.
Why this answer
Registering api.example.com with a ServiceEntry places it in the mesh service registry so the sidecar can route to it. Setting the Sidecar's outboundTrafficPolicy to REGISTRY_ONLY changes the default behavior from allowing unknown passthrough to rejecting anything not in the registry. Together they permit exactly the intended external API while blocking all other unregistered external hosts, matching the selective egress requirement.
Exam trap
The trap here is assuming that a DestinationRule or Gateway can make an unknown external host reachable, when only a ServiceEntry adds it to the registry.
You are troubleshooting a service that is failing to communicate with another service in a different namespace. Which TWO of the following items should you check to ensure connectivity?
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.
Why this answer
In an Istio service mesh, cross-namespace communication failures are most commonly caused by security policies, so you should verify PeerAuthentication settings (B), which define the mutual TLS mode (STRICT, PERMISSIVE, DISABLE) and can block traffic if one namespace requires mTLS while the other does not present a valid certificate. You should also check AuthorizationPolicy rules (E), since these enforce L7 access control (ALLOW/DENY/CUSTOM) and a policy in the destination namespace can silently reject requests from the source namespace's service account. The other options are unrelated to connectivity: Kiali's theme (A) is purely a UI preference, the ingress gateway version (C) affects north-south traffic entering the mesh rather than east-west service-to-service calls, and the total number of sidecars (D) is a cluster-wide metric that does not determine whether two specific services can reach each other.
Exam trap
ICA often tests whether candidates know that east-west traffic does not traverse the ingress gateway — the trap is picking the ingress gateway version as a connectivity check when it is irrelevant for service-to-service calls.
You manage an Istio mesh with two ingress gateways: one public, one private. You need to allow external clients to reach a service through the public gateway, but only if they present a valid client certificate. The private gateway must remain unaffected. Which Istio resource should you configure to enforce this requirement at the public gateway?
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.
Why this answer
The correct approach is to configure the public ingress gateway with a Gateway resource that uses TLS mode MUTUAL and references a secret containing the CA certificate for client validation. This enforces client certificate authentication at the gateway level without affecting the private gateway, which can retain its own configuration. PeerAuthentication and RequestAuthentication do not provide client certificate validation at the gateway, and AuthorizationPolicy cannot enforce certificate-based authentication.
You are troubleshooting why a client cannot reach a service in another namespace within the same mesh. The client's sidecar shows the destination cluster exists, but requests fail. You want to verify whether the client's proxy has the correct listener and route for the destination's port. Which istioctl command sequence should you use?
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.
Why this answer
istioctl proxy-status first confirms the client proxy is synchronized with istiod, ruling out stale config. Then istioctl proxy-config listeners and routes against the client pod enumerate the actual listener for the destination port and the route entries matching the destination host. This directly verifies whether the proxy has the expected listener and route, which is what the scenario asks.
Exam trap
The trap here is using istioctl analyze or kubectl exec to infer proxy state, when only proxy-config listeners and routes expose the actual proxy configuration.
In a multi-cluster environment with a shared control plane, what is the purpose of the 'istio-remote-secret'?
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.
Why this answer
In Istio's multi-cluster model with a shared (primary) control plane, the istio-remote-secret is a Secret created in the primary cluster that contains the kubeconfig credentials for a remote cluster. It allows the primary control plane (istiod) to connect to and manage the remote cluster's API server — discovering its services, endpoints, and injecting configuration — so the remote cluster's workloads participate in the mesh.
Exam trap
The trap is assuming the istio-remote-secret handles encryption or identity, when its actual role is to give the primary control plane API access to a remote cluster for service discovery and configuration — encryption is mTLS's job, and identity comes from SPIFFE certs.
How to eliminate wrong answers
Option A is wrong because custom headers for cross-cluster traffic are configured in VirtualService/DestinationRule or via Envoy filters, not in the istio-remote-secret. Option B is wrong because cluster identity in the mesh is established through the cluster name in the kubeconfig context and the SPIFFE identity in certificates, not by the remote secret itself — the secret carries credentials, not an identity label. Option D is wrong because traffic encryption between clusters is handled by mutual TLS (mTLS) using SPIFFE certificates issued by istiod's CA, not by the remote secret, which is purely an access/credential mechanism.
Which TWO settings in a DestinationRule are used for load balancing?
Defines the simple load balancing algorithm (e.g., ROUND_ROBIN).
Why this answer
TrafficPolicy includes the load balancing settings for a service.
When inspecting Envoy stats, what does 'upstream_rq_timeout' represent?
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.
Why this answer
This metric indicates the number of requests that timed out while waiting for a response from the upstream service.
Which THREE of the following are valid ways to control egress traffic in Istio?
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.
Why this answer
Egress control can be achieved via mesh-level configuration, gateway-based routing, or sidecar-level restrictions.
When configuring a Gateway API resource, which TWO properties are defined within the 'listeners' block?
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.
Why this answer
In the Gateway API, each entry in the 'listeners' block defines how the gateway accepts traffic, and two of its core required fields are the port and the protocol. Option B (Port) is correct because a listener must specify the network port on which the gateway listens for incoming connections, such as port 80 or 443. Option D (Protocol) is correct because a listener must declare the protocol it handles, such as HTTP, HTTPS, TLS, or TCP, which determines how traffic on that port is processed.
The other options do not belong in the 'listeners' block: request retries (A) and circuit breaker policy (C) are traffic-management policies typically expressed in HTTPRoute or backend policy resources, while a service account (E) is a Kubernetes identity object unrelated to listener configuration.
You are using Kiali to debug a service mesh. You notice a red line between two services. What does this indicate?
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.
Why this answer
In Kiali's graph view, edge colors encode traffic health: green means healthy, yellow means degraded, and red means the request/response flow is failing. A red line specifically indicates that the destination workload is returning errors (typically 5xx) or that traffic is being denied by an Istio policy such as an AuthorizationPolicy or a misconfigured PeerAuthentication. Kiali derives this from Envoy sidecar telemetry (istio_requests_total), so the red edge is a symptom of actual request failures, not a topology or encryption state.
Exam trap
The trap here is confusing Kiali's visual encodings — candidates assume red means a topology/configuration problem (different cluster, not in mesh) rather than the actual meaning: failing or policy-blocked traffic.
How to eliminate wrong answers
Option A is wrong because cross-cluster placement is not represented by edge color in Kiali — multi-cluster topology is shown via cluster badges/annotations, not red lines. Option C is wrong because a service outside the mesh is typically rendered as a gray or dashed node/edge (or missing telemetry), not a red edge; mesh membership is a node attribute, not a traffic-health signal. Option D is wrong because mTLS encryption is indicated by a padlock icon on the edge, not by color — encrypted-but-healthy traffic still shows green.
You are deploying a new version of a microservice in your Istio mesh. You want to perform a canary rollout where 10% of traffic goes to the new version, but you also want to ensure that requests from a specific test user always go to the new version regardless of the overall percentage. Which Istio traffic management feature should you use to achieve this?
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.
Why this answer
The VirtualService is the core Istio resource for traffic routing. It supports matching on HTTP headers, path, method, etc., and can route to different destinations with weights. By combining a header match for the test user with a weighted route for the rest, you achieve both the canary percentage and the sticky routing for that user.
This is a common pattern for progressive delivery.
Exam trap
The trap here is confusing the roles of VirtualService and DestinationRule; the DestinationRule defines subsets but does not route traffic.
What is the result of setting 'outlierDetection' in a DestinationRule?
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.
Why this answer
The outlierDetection field in an Istio DestinationRule configures outlier ejection, which is Istio's implementation of passive health checking. When an endpoint in the load balancing pool returns a consecutive number of 5xx errors (default consecutive5xxErrors: 5) within a defined interval, Envoy ejects that endpoint from the pool for a base ejection time (default 30s), preventing traffic from being routed to the unhealthy pod. This is analogous to circuit breaking at the endpoint level and improves overall service reliability without requiring active health checks.
Exam trap
The trap here is confusing outlierDetection (passive endpoint ejection) with active health checks or circuit breaking — candidates often pick 'retries' because both relate to resilience, but retries are configured in VirtualService, not DestinationRule.
How to eliminate wrong answers
Option A is wrong because log forwarding to a remote collector is handled by telemetry components such as Fluent Bit, Fluentd, or the Istio access log configuration, not by DestinationRule outlierDetection. Option B is wrong because automatic retries are configured via the retries field in a VirtualService (or Envoy retry policy), not outlierDetection. Option C is wrong because connection encryption is provided by mTLS configuration in a PeerAuthentication policy or the trafficPolicy.tls settings, not by outlier detection.
Your team wants to ship an application's logs and metrics to a centralized platform without redeploying the application or changing its code. The application already runs with an injected sidecar. Which Istio capability should you use to emit telemetry to an external backend?
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.
Why this answer
The Telemetry API provides declarative configuration for metrics, access logs, and traces across mesh workloads. By defining providers such as OpenTelemetry and selecting the signals to emit, you can route telemetry to a centralized backend without modifying or redeploying the application. It is the supported extension point for observability export and avoids brittle low-level Envoy patching.
Exam trap
The trap here is confusing traffic mirroring or Sidecar scoping with telemetry export, when only the Telemetry API declares providers and signals.
You are using Istio's telemetry features to monitor your mesh. You want to collect metrics on the number of requests that result in a 5xx error for a specific service. Which Istio component is responsible for generating these metrics?
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.
Why this answer
Envoy sidecar proxies are the data plane components that handle all service traffic. They are instrumented to emit detailed metrics for each request, including response codes. These metrics are then scraped by Prometheus and can be visualized in tools like Kiali.
The control plane (istiod) configures the proxies but does not generate traffic metrics.
Exam trap
The trap here is attributing metric generation to the monitoring system (Prometheus) or the control plane, when it is actually the data plane proxies that produce the raw metrics.
How can you verify the current configuration being pushed to an Envoy sidecar without using Kiali?
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.
Why this answer
The `istioctl proxy-config` command retrieves the actual Envoy configuration (clusters, listeners, routes, endpoints) from a specific sidecar, allowing you to verify what is currently pushed without Kiali. It queries the Envoy admin API on the proxy and formats the output. This is the standard CLI method for inspecting sidecar config.
Exam trap
ICA often tests the confusion between configuration resources (VirtualService, etc.) and the actual Envoy config, leading candidates to pick `kubectl get virtualservice` instead of `istioctl proxy-config`.
How to eliminate wrong answers
Option A is wrong because `istioctl analyze` performs static analysis of Istio configuration for potential issues; it does not show the live Envoy config pushed to a sidecar. Option B is wrong because `kubectl get virtualservice` shows the Istio VirtualService resource, not the Envoy configuration that results from it; it does not verify what the sidecar actually received. Option D is wrong because `kubectl describe pod` shows Kubernetes pod metadata and events, not the Envoy proxy configuration.
What is the primary function of the 'PeerAuthentication' resource?
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.
Why this answer
PeerAuthentication allows you to define the mTLS mode (STRICT, PERMISSIVE, DISABLE) for workloads within a namespace or the entire mesh.
You want to force all traffic to an external service to go through an EgressGateway. What is required?
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.
Why this answer
A ServiceEntry to register the external host, and a VirtualService to route that traffic to the EgressGateway.
A production mesh shows intermittent 503 responses from one service. You suspect the sidecar's circuit breaker is tripping. You need to confirm which outlier-detection and connection-pool settings are active for that destination. Which Istio resource holds these settings, and how do you inspect them at runtime?
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.
Why this answer
Connection pool limits and outlier detection are declared under a DestinationRule's trafficPolicy for a given host. The sidecar translates those into Envoy cluster settings, so istioctl proxy-config cluster is the authoritative way to see the effective circuit breaker thresholds on the proxy. Together they let you confirm whether the intermittent 503s stem from active breaker or pool limits.
Exam trap
The trap here is looking at VirtualService routes or PeerAuthentication for circuit breaking, when those settings belong to DestinationRule clusters.
Which TWO actions can be taken via the 'istioctl' command to debug mesh health?
`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`.
Why this answer
Option D, 'istioctl analyze', is correct because it statically inspects the mesh configuration (Istio resources, namespaces, and optionally live cluster state) and reports potential misconfigurations, warnings, and errors that affect mesh health. Option E, 'istioctl proxy-config', is correct because it queries the Envoy configuration of a specific sidecar or gateway (for example, clusters, listeners, routes, endpoints, and bootstrap) to diagnose traffic-routing and connectivity problems in the mesh. The other options are not valid istioctl debugging actions: 'istioctl delete pod' (A) is not an istioctl subcommand for deleting pods, 'istioctl monitor' (B) is not a supported istioctl command for mesh health monitoring, and 'istioctl update mesh' (C) is not a valid istioctl command for updating mesh configuration.
Which Istio component handles the generation of xDS configuration?
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.
Why this answer
Istiod is the monolithic control plane component that computes the configuration for all sidecars.
You are troubleshooting a production Istio mesh where a critical service is experiencing intermittent 503 errors. You suspect that the Envoy sidecar is rejecting requests due to a misconfiguration in the DestinationRule. Which Istio command would you use to inspect the Envoy configuration for a specific pod to verify the applied outlier detection settings?
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.
Why this answer
Outlier detection settings are part of the Envoy cluster configuration. To view them, you need to inspect the cluster configuration in detail. The istioctl proxy-config cluster command with JSON output provides the complete cluster definition, including outlier detection, allowing you to verify if the settings are causing the 503 errors due to unhealthy hosts being ejected.
Exam trap
The trap here is confusing the level at which outlier detection is configured; it is a cluster-level setting, not a listener or route setting.
What is the main advantage of using Istio's 'locality-aware load balancing'?
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.
Why this answer
It prioritizes traffic to endpoints in the same zone or region to reduce latency and egress costs.
Which tool allows you to perform traffic shifting between two versions of a service?
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.
Why this answer
A VirtualService is used to define traffic weights for different subsets (versions) defined in a DestinationRule.
You are running an Istio mesh with several clusters. You need to ensure that all outbound traffic from the mesh to external services is visible and controlled. You have already configured a ServiceEntry for an external API at api.external.com. However, you notice that traffic to this API is not being logged in Kiali and no telemetry is collected. What is the most likely cause?
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.
Why this answer
ServiceEntry resources are namespace-scoped but can be exported to other namespaces using the exportTo field. If a client pod is in a namespace that does not have access to the ServiceEntry, its sidecar will not have the routing configuration, and traffic to the external service will not be captured or logged. Ensuring proper export settings is crucial for mesh-wide visibility.
Exam trap
The trap here is assuming that ServiceEntry automatically applies to all namespaces without considering the exportTo field, which can restrict visibility.
In a multi-tenancy setup, which Istio resource should you use to restrict which namespaces a sidecar can see?
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.
Why this answer
Sidecar resources can be used to limit the scope of service discovery, effectively hiding services in other namespaces.
Which TWO pieces of information are displayed in the Kiali 'Graph' view?
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.
Why this answer
Option B is correct because the Kiali Graph view overlays health status on the topology, coloring nodes and edges to indicate errors and warnings (for example, red for errors and yellow for warnings) so operators can quickly spot unhealthy services. Option C is correct because the Graph view's core purpose is visualizing service-to-service traffic flow within the Istio service mesh, showing how requests move between workloads, services, and other mesh components. Option A is not shown, as the graph depicts mesh entities like services and workloads rather than Kubernetes node IP addresses.
Option D is not displayed, since sidecar (Envoy proxy) image versions are not part of the graph's traffic topology visualization. Option E is not included, as user login history is unrelated to the Kiali Graph view's traffic and health representation.
When designing for high availability in a multi-cluster Istio mesh, which THREE strategies are recommended?
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.
Why this answer
Locality-aware load balancing (B) is recommended because Istio's LocalityLoadBalancerSetting prioritizes endpoints in the same region/zone before failing over to remote localities, reducing latency and cross-cluster traffic while preserving availability. Cross-cluster service failover (D) is correct because Istio's multi-cluster mesh (via east-west gateways and remote secrets) lets a service in one cluster route to healthy endpoints in another cluster when local endpoints fail, which is the core of HA across clusters. Running the control plane in multiple clusters (E) is correct because deploying istiod in each cluster (replicated control plane model) removes a single point of failure and lets each cluster's sidecars obtain configuration even if another cluster's control plane is unreachable.
Disabling mTLS (A) is not recommended: it weakens zero-trust security and does not meaningfully improve HA, and mTLS overhead is minimal. Using a single ingress gateway for all traffic (C) is not recommended because it creates a single point of failure and a cross-cluster bottleneck, contradicting HA design.
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?
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.
Ready to test yourself?
Try a timed practice session using only Scenario questions.