ICA Practice Test 18 — 15 Questions

Question 1

You need to restrict traffic to a specific subset of a service defined in a DestinationRule. What should you use in your VirtualService destination block?

Accepted Answer

subset. The subset field in the destination object refers to the named subset in the DestinationRule.

Answer

host

Answer

weight

Answer

port

Question 2

Which TWO of the following are valid ways to verify the status of an Istio control plane deployment?

Accepted Answer

istioctl verify-install. Option A, `istioctl verify-install`, is correct because this command validates that the Istio control plane (and other components) were installed correctly by checking the deployed resources against the installation manifest, reporting any missing or misconfigured components such as istiod. Option B, `kubectl get deploy istiod -n istio-system`, is correct because istiod is the Istio control plane deployment, and querying its Deployment in the istio-system namespace directly shows whether the control plane pods are running and available. Option C, `istioctl proxy-status`, is not correct here because it reports the synchronization status of sidecar proxies (Envoy) with the control plane, not the control plane deployment's own status. Option D, `istioctl mesh-check`, is not a valid istioctl command. Option E, `kubectl describe ingressgateway`, is not valid because ingressgateway is not a Kubernetes resource kind; the gateway is typically a Deployment/Service, and this command would fail.

Answer

istioctl proxy-status

Answer

istioctl mesh-check

Answer

kubectl describe ingressgateway

Question 3

What information can you get from 'istioctl proxy-config'? (Choose THREE)

Accepted Answer

clusters. The `istioctl proxy-config` command (often abbreviated `pc`) inspects the Envoy sidecar configuration generated for a specific workload, and its subcommands map directly to Envoy's xDS configuration sections. Option C (clusters) is correct because `istioctl proxy-config clusters` lists the upstream clusters Envoy knows about, including the service and subset clusters derived from Istio's service registry. Option D (endpoints) is correct because `istioctl proxy-config endpoints` shows the load-balancing endpoints (host:port members) that back each cluster, i.e., the resolved instances of a service. Option E (routes) is correct because `istioctl proxy-config routes` dumps the route configurations (virtual hosts and route rules) that Envoy uses to match and forward traffic. Options A (virtualservices) and B (deployments) are not part of `proxy-config`: VirtualService is an Istio Kubernetes CRD inspected with `kubectl get virtualservice` or `istioctl analyze`, and Deployments are Kubernetes workload objects retrieved with `kubectl get deployments`, neither of which reflects Envoy's runtime proxy configuration.

Answer

virtualservices

Answer

deployments

Question 4

Your team runs a payments service in the 'prod' namespace with a Kubernetes Service named 'payments' listening on port 8443. During a canary rollout you created a Gateway 'payments-gw' in the 'istio-system' namespace and a VirtualService 'payments-vs' in the 'prod' namespace that references the gateway as 'payments-gw'. Clients report HTTP 404 errors when calling the service, but the sidecar-injected payments pods show healthy endpoints and the Gateway pod logs report 'no matching route'. Which change resolves the routing failure?

Accepted Answer

Change the VirtualService gateway reference to 'istio-system/payments-gw'.. A VirtualService binds to a Gateway by name, and that name is resolved relative to the VirtualService's own namespace. When the Gateway is in a different namespace, the reference must be fully qualified as '/'. Because the Gateway and VirtualService here live in different namespaces, the unqualified reference fails to bind, so the Gateway has no route and returns 404. Qualifying the reference restores the binding.

Answer

Move the payments-vs VirtualService into the istio-system namespace.

Answer

Add 'exportTo: ["*"]' to the payments-vs VirtualService.

Answer

Add a 'hosts' entry for 'payments.prod.svc.cluster.local' to the payments-gw Gateway.

Question 5

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?

Accepted Answer

Gateway with TLS mode MUTUAL and a credentialName referencing a Kubernetes secret containing the CA certificate and server certificate/key.. 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.

Answer

RequestAuthentication with a JWT rule applied to the public gateway's workload selector.

Answer

AuthorizationPolicy with a when condition on source.namespace applied to the public gateway.

Answer

PeerAuthentication with mtls.mode: STRICT applied to the public gateway's workload selector.

Question 6

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?

Accepted Answer

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.. 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.

Answer

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

Answer

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

Answer

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

Question 7

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?

Accepted Answer

Istio's Telemetry API with providers configured to send metrics and access logs to the external backend.. 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.

Answer

A Sidecar resource with egress listeners that mirror traffic to an external observability service.

Answer

A VirtualService with a mirror destination that copies every request to the observability platform.

Answer

EnvoyFilter that patches the sidecar's HTTP connection manager to forward access logs to a remote collector.

Question 8

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?

Accepted Answer

DestinationRule holds them; inspect the generated Envoy config with istioctl proxy-config cluster for the destination.. 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.

Answer

VirtualService holds them; inspect with istioctl proxy-config route for the destination's host.

Answer

Gateway holds them; inspect with istioctl proxy-config listener on the ingress gateway pod.

Answer

PeerAuthentication holds them; inspect with istioctl authn tls-check for the destination workload.

Question 9

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?

Accepted Answer

VirtualService with HTTP route matching on headers and weighted destinations. 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.

Answer

ServiceEntry with resolution: STATIC and endpoints

Answer

DestinationRule with subset and trafficPolicy

Answer

Sidecar with outboundTrafficPolicy: REGISTRY_ONLY

Question 10

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?

Accepted Answer

A ServiceEntry that defines api.example.com with protocol HTTPS and resolution DNS, plus a Sidecar resource with an outboundTrafficPolicy of REGISTRY_ONLY.. 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.

Answer

A PeerAuthentication with mtls.mode STRICT in the payments namespace, plus an EnvoyFilter that rewrites the Host header for api.example.com.

Answer

A Gateway resource with servers for port 443 and hosts set to api.example.com, plus a VirtualService that routes to an external ServiceEntry.

Answer

A DestinationRule with trafficPolicy tls.mode SIMPLE targeting api.example.com, plus a Sidecar with outboundTrafficPolicy ALLOW_ANY.

Question 11

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?

Accepted Answer

istioctl proxy-config cluster -n -o json. 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.

Answer

istioctl proxy-config route -n

Answer

istioctl proxy-config cluster -n

Answer

istioctl proxy-config listener -n

Question 12

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?

Accepted Answer

istioctl proxy-status, then istioctl proxy-config listeners and istioctl proxy-config routes for the client pod.. 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.

Answer

kubectl exec into the client pod and run curl against the destination, then check the sidecar container logs.

Answer

istioctl analyze --all-namespaces, then istioctl validate -f on the destination's manifests.

Answer

istioctl x describe pod on the destination, followed by istioctl experimental wait for the mesh.

Question 13

Your team runs an Istio service mesh in STRICT mutual TLS mode across the cluster. A new workload in the 'payments' namespace must accept only traffic from workloads that present a SPIFFE identity of 'cluster.local/ns/payments/sa/payment-processor'. All other inbound traffic, including from other namespaces, must be denied. You create an AuthorizationPolicy in the 'payments' namespace. Which configuration correctly enforces this requirement?

Accepted Answer

Set action: ALLOW with rules matching source.principals: ["cluster.local/ns/payments/sa/payment-processor"].. In Istio, when at least one ALLOW AuthorizationPolicy selects a workload, the default becomes deny-all except what the ALLOW rules permit. Specifying source.principals with the exact SPIFFE ID restricts inbound traffic to the payment-processor service account. Other identities are implicitly denied. This is the canonical way to enforce service-account-level least privilege in a STRICT mTLS mesh.

Answer

Set action: DENY with rules matching source.principals: ["cluster.local/ns/payments/sa/payment-processor"].

Answer

Set action: ALLOW with rules matching source.ipBlocks: ["10.0.0.0/8"] and source.principals: ["cluster.local/ns/payments/sa/payment-processor"].

Answer

Set action: ALLOW with rules matching source.namespaces: ["payments"] and source.principals: ["*"].

Question 14

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?

Accepted Answer

Envoy sidecar proxies. 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.

Answer

istiod

Answer

Kiali

Answer

Prometheus

Question 15

You want to enforce that only requests with a valid JWT issued by 'https://accounts.example.com' are allowed to access the 'orders' service. You have applied a RequestAuthentication policy. What additional step is required to actually block requests without a valid JWT?

Accepted Answer

Apply an AuthorizationPolicy with an ALLOW action that requires a valid JWT principal.. RequestAuthentication validates JWTs but does not reject requests without one. To enforce JWT presence, you need an AuthorizationPolicy that allows only requests with a validated JWT principal. This is typically done by matching on 'requestPrincipals', which is set after successful validation. The ALLOW policy will deny any request that does not have a valid JWT, effectively blocking unauthorized access.

Answer

Add a DENY AuthorizationPolicy that blocks all requests without a JWT.

Answer

Configure a PeerAuthentication policy with mode STRICT to require client certificates.

Answer

Modify the RequestAuthentication policy to set 'forwardOriginalToken: true'.