ICA Practice Test 16 — 15 Questions

Question 1

Which command lists all virtual services in the current namespace?

Accepted Answer

kubectl get virtualservices. kubectl get virtualservices is the standard command to list this CRD.

Answer

istioctl virtualservices

Answer

istioctl get vs

Answer

istioctl list virtualservice

Question 2

You want to limit the number of concurrent connections to a service. Which field in the DestinationRule handles this?

Accepted Answer

connectionPool. The connectionPool field in the trafficPolicy allows setting maxConnections for circuit breaking.

Answer

outlierDetection

Answer

loadBalancer

Answer

portLevelSettings

Question 3

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?

Accepted Answer

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

Answer

Kiali's current theme settings.

Answer

The Istio ingress gateway version.

Answer

The number of sidecars running in the cluster.

Question 4

You want to ensure that a request to the 'search' service fails fast if it takes longer than 2 seconds. How is this configured?

Accepted Answer

In the VirtualService, set 'timeout: 2s' in the route rule.. In Istio, request timeouts are configured in the VirtualService resource, specifically within the HTTP route rule using the 'timeout' field (e.g., 'timeout: 2s'). This tells the Envoy sidecar to abort the request if it doesn't receive a response from the destination within the specified duration, causing the client to receive a 504 Gateway Timeout. The timeout is applied per route, allowing granular control over different services or subsets. This is the standard and documented way to enforce fail-fast behavior for a service like 'search'.

Answer

In the EnvoyFilter, set 'timeout: 2s'.

Answer

In the Gateway, set 'timeout: 2s'.

Answer

In the DestinationRule, set 'timeout: 2s'.

Answer

In the ServiceEntry, set 'timeout: 2s'.

Question 5

If you apply an AuthorizationPolicy with a 'DENY' action and an 'ALLOW' action in the same namespace, how does Istio resolve them?

Accepted Answer

DENY policies always take precedence over ALLOW policies.. Istio's AuthorizationPolicy evaluation follows a deny-overrides model: if any DENY policy matches a request, the request is rejected regardless of any matching ALLOW policies. ALLOW policies are only evaluated if no DENY policy matches, and if at least one ALLOW policy exists in the namespace, a request must match one to be permitted. This ordering is enforced by the Envoy RBAC filter that Istio programs into the sidecar.

Answer

ALLOW policies take precedence.

Answer

The policy with the highest priority field wins.

Answer

The policy applied most recently wins.

Question 6

Which TWO actions can a VirtualService perform on a request?

Accepted Answer

Rewrite URI. Option C (Rewrite URI) is correct because an Istio VirtualService supports the `rewrite` field under `http` routes, allowing the request's URI or authority to be rewritten before forwarding to the destination, e.g., `rewrite: uri: /v1/...`. Option D (Redirect request) is correct because a VirtualService supports the `redirect` field, which returns an HTTP redirect (with `uri`, `authority`, and `redirectCode` such as 301 or 302) instead of routing the request to a backend. The other options do not belong: bandwidth throttling (A) is not a VirtualService capability (it would be handled by traffic-shaping tools or Envoy rate limiting/filters), mTLS mode (B) is configured via PeerAuthentication and DestinationRule, and traffic encryption (E) is handled by mTLS at the transport layer, not by VirtualService routing rules.

Answer

Throttle bandwidth

Answer

Define mTLS mode

Answer

Encrypt traffic

Question 7

Which THREE actions occur when 'mode: STRICT' is set in a PeerAuthentication policy?

Accepted Answer

The client proxy initiates mTLS handshakes.. In Istio, setting mode: STRICT in a PeerAuthentication policy enforces mutual TLS for all workloads in the targeted scope, so option B is correct because the client-side Envoy proxy initiates the mTLS handshake with the server proxy, presenting its certificate. Option C is correct because the receiving sidecar proxy validates the peer's identity by verifying the presented X.509 certificate against the trusted CA (Istiod's root), which is the core of mTLS peer authentication. Option E is correct because in STRICT mode the server proxy rejects any plaintext (non-mTLS) traffic, allowing only connections that complete a valid mTLS handshake. Option A is wrong because PeerAuthentication only governs transport authentication between sidecars; it does not reroute non-Istio traffic to an ingress gateway. Option D is wrong because automatic HTTP-to-HTTPS redirection is a feature of Gateway/VirtualService or the istio-ingressgateway configuration, not of PeerAuthentication STRICT mode.

Answer

All non-Istio traffic is automatically routed to the gateway.

Answer

The proxy automatically upgrades HTTP to HTTPS.

Question 8

When multiple AuthorizationPolicies target the same workload, how are they combined?

Accepted Answer

Policies are unioned (OR logic) for ALLOW actions.. If multiple policies are applied to the same workload, they are evaluated using an additive approach (OR logic) for ALLOW policies within the same namespace.

Answer

The most specific policy wins, others are ignored.

Answer

The first policy encountered in the API server wins.

Answer

All policies must match (AND logic).

Question 9

Which are valid match conditions in VirtualService? (Choose THREE)

Accepted Answer

headers. In Istio's VirtualService, the HTTPMatchRequest object defines the conditions used to select which route applies to a request, and its valid fields include headers (A), uri (C), and port (E). Option A (headers) is correct because HTTPMatchRequest supports a headers map that matches request headers by exact, prefix, or regex value. Option C (uri) is correct because uri is a core match field supporting exact, prefix, and regex matching on the request path. Option E (port) is correct because HTTPMatchRequest includes a port field that matches the destination port number of the request. Option B (timeout) is not a match condition; it is a route-level setting that specifies how long to wait for a response before aborting. Option D (weight) is not a match condition either; it is a destination-level field used to distribute traffic across subsets in a weighted route.

Answer

timeout

Answer

weight

Question 10

Which THREE are types of traffic management patterns?

Accepted Answer

Canary deployment. Canary deployment (A) is a traffic management pattern in which a small percentage of live traffic is routed to a new version of a service so its behavior can be validated before a full rollout, typically implemented via weighted routing in a service mesh or load balancer. Circuit breaking (B) is a traffic management pattern that monitors failure rates and, once a threshold is exceeded, trips the circuit to stop sending requests to an unhealthy backend, preventing cascading failures and allowing recovery. Traffic mirroring (C) is a traffic management pattern that duplicates production traffic (often via shadowing in Istio or AWS VPC Traffic Mirroring) and sends a copy to a test or analysis target without affecting the original request path. Namespace isolation (D) is a Kubernetes organizational and security construct for scoping resources, RBAC, and network policies, not a traffic management pattern. Database sharding (E) is a data partitioning/scalability technique that distributes rows across multiple databases, not a pattern for managing service traffic.

Answer

Namespace isolation

Answer

Database sharding

Question 11

Which of the following are valid traffic management components in Istio? (Choose TWO)

Accepted Answer

VirtualService. VirtualService (C) is a core Istio traffic management resource that defines how requests are routed to a service in the mesh, including match conditions, retries, timeouts, fault injection, and traffic splitting rules. DestinationRule (E) is also a core Istio traffic management resource that configures policies applied after routing, such as load balancing algorithms, connection pool settings, outlier detection, and subsets used by VirtualService routes. Together, VirtualService and DestinationRule form the standard Istio routing pair for controlling traffic behavior. The other options are Kubernetes resources, not Istio traffic management components: ClusterRole (A) and ServiceAccount (D) are RBAC/identity objects, and Deployment (B) is a workload controller for managing pods.

Answer

ClusterRole

Answer

Deployment

Answer

ServiceAccount

Question 12

Which TWO Istio components can be configured via the 'spec.components' section in IstioOperator?

Accepted Answer

pilot. The IstioOperator custom resource's spec.components section is used to enable, disable, and configure the core Istio control-plane and gateway components, and pilot (A) is one of them — it controls the istiod deployment (the merged Pilot/Citadel/Galley control plane), so it is correctly configured here. ingressGateways (B) is also part of spec.components, where you define gateway deployments such as istio-ingressgateway with their k8s settings, so it is correct as well. The add-on components prometheus (C), kiali (D), and jaeger (E) are not configured under spec.components; they are optional observability add-ons installed separately (e.g., via samples/addons manifests or the istioctl dashboard commands) and are not part of the IstioOperator components schema.

Answer

prometheus

Answer

kiali

Answer

jaeger

Question 13

When planning an Istio upgrade, which THREE steps are critical for a canary upgrade strategy?

Accepted Answer

Install the new version as a separate revision. Option A is correct because Istio's canary upgrade model requires installing the new control plane as a separate revision (e.g., istioctl install --set revision=canary), which creates a distinct istiod deployment and webhook so the old and new versions coexist. Option B is correct because traffic to the new revision is enabled by labeling the target namespace with istio.io/rev=<new-revision>, which causes the sidecar injector webhook for that revision to inject the new proxy version into pods. Option E is correct because existing pods still run the old sidecar; restarting the application pods in the namespace triggers re-injection so the new revision's proxy is actually applied. Option C is wrong because an in-place upgrade of the existing istiod replaces the control plane rather than running revisions side by side, defeating the canary approach. Option D is wrong because deleting the old IstioOperator CR is not part of the canary process and would remove the old revision's configuration before migration is complete.

Answer

Perform an in-place upgrade of the existing istiod

Answer

Delete the old IstioOperator CR

Question 14

You need to ensure that traffic is only routed to healthy pods. What feature does this?

Accepted Answer

DestinationRule outlierDetection. Outlier detection in DestinationRule ejects unhealthy hosts from the load balancing pool.

Answer

ServiceEntry registry

Answer

PeerAuthentication

Answer

VirtualService weight

Question 15

Which THREE settings are required in a VirtualService for a canary deployment?

Accepted Answer

http routes. In an Istio VirtualService, a canary deployment is expressed through HTTP routing rules, so option B (http routes) is required because the http stanza holds the match and route entries that split traffic between the stable and canary subsets. Option D (weight) is required because each route destination must carry a weight value (for example 90/10) so the mesh can distribute traffic proportionally between the two versions. Option E (hosts) is required because the VirtualService must declare the destination hosts (the service DNS names, such as reviews.prod.svc.cluster.local) that the routing rules apply to. Options A (tcp) and C (tls) are not required here: tcp and tls are alternative protocol-specific stanzas used for TCP or TLS routing, and a canary deployment based on HTTP traffic does not need them.

Answer

tcp

Answer

tls