ICA Traffic Management Practice Test 6 — 15 Questions

Question 1

What is the purpose of the 'istio-system' namespace?

Accepted Answer

Control plane. It contains the Istio control plane components.

Answer

Ingress only

Answer

App storage

Answer

Proxy logs

Question 2

Which field in VirtualService is used for A/B testing?

Accepted Answer

weight. The weight field is used to split traffic between versions (subsets) for A/B testing.

Answer

redirect

Answer

match

Answer

subset

Question 3

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 4

Which parameters can be configured in a VirtualService retry policy? (Choose TWO)

Accepted Answer

attempts. In Istio's VirtualService HTTP retry policy, the retry block supports fields such as attempts, perTryTimeout, retryOn, and retryRemoteLocalities, so option B (attempts) is correct because it specifies the maximum number of retry attempts for a failed request, and option E (perTryTimeout) is correct because it sets the timeout for each individual retry attempt. The other options do not belong to the retry policy: maxConnections (A) and connectionPool (C) are DestinationRule traffic-policy settings controlling connection limits, and outlierDetection (D) is a DestinationRule setting for ejecting unhealthy hosts from the load-balancing pool.

Answer

maxConnections

Answer

connectionPool

Answer

outlierDetection

Question 5

You need to define a local service that is not in the cluster. How?

Accepted Answer

ServiceEntry. ServiceEntry with location: MESH_INTERNAL allows defining services that are technically outside the K8s registry but internal to the mesh.

Answer

DestinationRule

Answer

VirtualService

Answer

Gateway

Question 6

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 7

Which of the following are valid Gateway configurations? (Choose TWO)

Accepted Answer

servers. In Istio's Gateway resource, the `servers` field (option A) is a valid top-level configuration that defines the ports, protocols, hosts, and TLS settings the gateway listens on, making it a required part of any Gateway spec. The `selector` field (option C) is also valid and specifies which Envoy proxy pods (via label matching, e.g., `istio: ingressgateway`) should apply the gateway configuration. Options B (`subsets`) and E (`endpoints`) belong to DestinationRule and Service/Endpoint resources respectively, not Gateway, and option D (`retry`) is a traffic-policy setting found in VirtualService or DestinationRule, so none of these are valid Gateway fields.

Answer

subsets

Answer

retry

Answer

endpoints

Question 8

Which items can be configured under DestinationRule trafficPolicy? (Choose THREE)

Accepted Answer

connectionPool. In Istio, a DestinationRule's trafficPolicy block governs how traffic is handled after routing has selected a destination, and it explicitly supports connectionPool (A), which sets TCP/HTTP connection limits such as maxConnections, http1MaxPendingRequests, and http2MaxRequests for the destination's sidecar connections. It also supports outlierDetection (D), which implements passive health checking by ejecting unhealthy hosts from the load-balancing pool based on consecutive 5xx errors or gateway failures. loadBalancer (E) is likewise a valid trafficPolicy field, configuring the algorithm (ROUND_ROBIN, LEAST_REQUEST, RANDOM, PASSTHROUGH) and consistent-hash options for distributing requests across the destination's endpoints. By contrast, rewrite (B) and headers (C) are HTTP route-level manipulations that belong to a VirtualService's route rules, not to DestinationRule trafficPolicy, so they are not configurable there.

Answer

rewrite

Answer

headers

Question 9

Which actions can a VirtualService perform on a request? (Choose TWO)

Accepted Answer

route. In Istio, a VirtualService defines how requests are routed to a service within the mesh, and its core capabilities include the route action (option A), which specifies destination hosts, subsets, and weights for matching traffic, and the headers action (option C), which allows modification of request and response headers via header manipulation rules. Both route and headers are valid top-level HTTP route actions in the VirtualService specification, making A and C correct for this scenario. The scale action (option B) is not part of VirtualService; scaling is handled by Kubernetes workload resources such as Deployments or HorizontalPodAutoscalers. The filter action (option D) is not a VirtualService action; traffic filtering is achieved through route match conditions or EnvoyFilter resources. The replicate action (option E) does not exist in the VirtualService API; traffic mirroring is instead configured using the mirror and mirrorPercentage fields under a route.

Answer

scale

Answer

filter

Answer

replicate

Question 10

Which resources control mTLS settings? (Choose TWO)

Accepted Answer

DestinationRule. In Istio, mTLS settings are controlled by two resources: DestinationRule and PeerAuthentication. DestinationRule (B) is correct because its trafficPolicy.tls.mode field (e.g., ISTIO_MUTUAL, DISABLE, SIMPLE, MUTUAL) configures how a client sidecar initiates TLS/mTLS to an upstream service. PeerAuthentication (C) is correct because its mtls.mode field (STRICT, PERMISSIVE, DISABLE) defines the server-side policy for whether a workload accepts mTLS connections. Gateway (A) configures ingress/egress TLS termination for external traffic, not service-to-service mTLS policy. ServiceEntry (D) registers external services into the mesh and does not set mTLS modes. VirtualService (E) handles routing rules (hosts, routes, retries) and has no mTLS configuration field.

Answer

Gateway

Answer

ServiceEntry

Answer

VirtualService

Question 11

Which of these are valid sub-commands for istioctl? (Choose TWO)

Accepted Answer

analyze. Option B, analyze, is a valid istioctl sub-command: `istioctl analyze` performs configuration analysis on Istio resources and reports potential issues such as misconfigurations or deprecated fields. Option C, proxy-config, is also valid: `istioctl proxy-config` (often abbreviated `pc`) retrieves Envoy configuration from a sidecar or gateway, with subcommands like `cluster`, `listener`, `route`, `endpoint`, and `bootstrap`. The other options are not istioctl sub-commands: restart and start are not provided by istioctl (workload restarts are done via kubectl or by deleting pods), and debug, while istioctl has diagnostic commands such as `proxy-status` and `experimental`, is not a valid top-level sub-command.

Answer

restart

Answer

start

Answer

debug

Question 12

Which of the following are valid DestinationRule fields? (Choose THREE)

Accepted Answer

host. In Istio's networking API, a DestinationRule is defined by the fields host, trafficPolicy, and subsets, so options B, C, and D are correct. The host field (B) is required and specifies the name of the service (or the Kubernetes service FQDN) to which the routing rules apply. The trafficPolicy field (C) defines policies such as load balancing, connection pool settings, outlier detection, and TLS settings applied to traffic to that host. The subsets field (D) defines named subsets of the service's endpoints (via labels) so that VirtualService routes can direct traffic to specific versions. Options A (redirect) and E (match) are not DestinationRule fields: redirect is a route action used in VirtualService HTTP/TCP route destinations, and match is used in VirtualService route matching conditions, not in DestinationRule.

Answer

redirect

Answer

match

Question 13

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 14

To perform a canary deployment, you have two versions of a service. Which resource do you use to split traffic between them?

Accepted Answer

VirtualService. In Istio, the VirtualService resource defines routing rules that determine how requests are matched and distributed to destinations. To split traffic between two versions of a service for a canary deployment, you configure weighted routes (e.g., 90/10) inside a VirtualService's http route block, each pointing to a subset defined in a DestinationRule.

Answer

DestinationRule

Answer

Gateway

Answer

Sidecar

Question 15

You need to expose a service to traffic outside the mesh using Istio. Which resource is required to configure the entry point for incoming traffic?

Accepted Answer

Gateway. The Gateway resource describes a load balancer operating at the edge of the mesh.

Answer

ServiceEntry

Answer

VirtualService

Answer

DestinationRule