ICA Multiple Select — 20 Questions

Question 1

Which TWO parameters affect the 'aggressiveness' of Outlier Detection?

Accepted Answer

interval. A short interval and a low consecutive error threshold make the system more aggressive.

Answer

baseEjectionTime

Answer

minHealthPercent

Answer

maxEjectionPercent

Question 2

Which TWO actions can be taken via the 'istioctl' command to debug mesh health?

Accepted Answer

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

Answer

istioctl delete pod

Answer

istioctl monitor

Answer

istioctl update mesh

Question 3

Which THREE factors influence whether a service in the mesh will accept traffic?

Accepted Answer

AuthorizationPolicy rules. In an Istio service mesh, whether a workload accepts traffic is governed first by AuthorizationPolicy rules (A), which define ALLOW/DENY/CUSTOM enforcement on incoming requests and determine if a request is permitted to reach the workload. PeerAuthentication policy mode (C) also matters because it controls the mutual TLS mode (STRICT, PERMISSIVE, DISABLE) for incoming connections, so a client that cannot satisfy the required mTLS mode will be rejected before application-level authorization. Envoy proxy configuration state (D) is decisive as well, since the sidecar's listeners, filter chains, and route/RBAC configs actually enforce acceptance; if the proxy is misconfigured, stale, or not synced with istiod, traffic may be refused regardless of the intended policy. The other options do not directly determine acceptance: MeshConfig proxyMetadata (B) only injects environment metadata into proxies and does not by itself gate traffic, and the Kubernetes Service port definition (E) merely exposes/forwards traffic at the L4 Service level without enforcing mesh authorization or mTLS acceptance.

Answer

Global MeshConfig 'proxyMetadata' settings

Answer

Kubernetes Service Port definition

Question 4

Which TWO mechanisms are used to secure traffic within the mesh?

Accepted Answer

PeerAuthentication. In Istio, PeerAuthentication is the correct mechanism for securing traffic within the mesh because it defines the mutual TLS (mTLS) mode (STRICT, PERMISSIVE, DISABLE) that governs how workloads authenticate each other's identities at the transport level. AuthorizationPolicy is also correct because it enforces access control on in-mesh traffic, deciding which identities (derived from mTLS) may perform which operations on which workloads. Together, PeerAuthentication establishes the cryptographic identity and encryption for service-to-service communication, while AuthorizationPolicy uses that identity to allow or deny requests inside the mesh. Gateway is not correct here because it manages ingress/egress traffic at the mesh edge, not intra-mesh security. VirtualService is not correct because it handles routing rules such as traffic splitting and retries, not security. ServiceEntry is not correct because it registers external services into the mesh registry, which is a service-discovery concern rather than a security mechanism.

Answer

Gateway

Answer

VirtualService

Answer

ServiceEntry

Question 5

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 6

Which TWO fields are mandatory in a Gateway resource?

Accepted Answer

selector. In an Istio Gateway resource, the servers field (E) is mandatory because it defines the ports, protocols, hosts, and TLS settings that the gateway listens on—without at least one server entry the gateway has nothing to configure. The selector field (C) is also mandatory since it binds the Gateway to the specific Envoy proxy pods (via labels such as istio: ingressgateway) that should implement the configuration. The subsets field (A) belongs to a DestinationRule's traffic policy, not to a Gateway, so it is not required here. The tls field (B) is optional and only needed when a server terminates or originates TLS. The hosts field (D) is configured inside each server entry, not as a top-level mandatory Gateway field.

Answer

subsets

Answer

tls

Answer

hosts

Question 7

Which TWO pieces of information are displayed in the Kiali 'Graph' view?

Accepted Answer

Health status (errors/warnings). 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.

Answer

Kubernetes node IP addresses

Answer

Sidecar image versions

Answer

User login history

Question 8

When designing for high availability in a multi-cluster Istio mesh, which THREE strategies are recommended?

Accepted Answer

Locality-aware load balancing. 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.

Answer

Disabling mTLS for performance

Answer

Using a single ingress gateway for all traffic

Question 9

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

Accepted Answer

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

Answer

grpc

Answer

tls

Question 10

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

Accepted Answer

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

Answer

retry

Answer

timeout

Answer

redirect

Question 11

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

Accepted Answer

interval. In Istio's DestinationRule, the outlierDetection block configures passive health checking (circuit breaking) that ejects unhealthy hosts from the load-balancing pool. Option A, interval, is correct because it defines the time interval between ejection sweep analyses of the hosts (e.g., 10s), controlling how often the outlier detection scan runs. Option B, baseEjectionTime, is correct because it specifies the minimum ejection duration for an outlier host, and the actual ejection time is multiplied by the number of times the host has been ejected. Option E, consecutive5xxErrors, is correct because it is the threshold of consecutive 5xx errors a host must return before it is ejected from the pool. Option C, requestRetryCount, is not part of outlierDetection; retry behavior is configured under the DestinationRule's trafficPolicy retries or the VirtualService retries block. Option D, maxConnectionTimeout, is not a valid outlierDetection field; connection pool timeouts are configured under connectionPool.tcp (e.g., connectTimeout) in the DestinationRule.

Answer

requestRetryCount

Answer

maxConnectionTimeout

Question 12

Which THREE items are included in an Istio SPIFFE ID?

Accepted Answer

Trust domain. An Istio SPIFFE ID follows the format spiffe:///ns//sa/, so the three components it includes are the trust domain (A), the namespace (D), and the service account (C). The trust domain (A) is the first segment after the spiffe:// scheme and identifies the identity's issuing authority, which in Istio defaults to cluster.local. The namespace (D) appears in the /ns/ path segment and scopes the workload identity to its Kubernetes namespace. The service account (C) appears in the /sa/ path segment and represents the Kubernetes service account under which the workload runs. Cluster Name (B) is not part of the SPIFFE ID format—it is a separate Istio concept used in multi-cluster configurations and mesh expansion. IP Address (E) is not encoded in a SPIFFE ID; Istio identities are based on service account and namespace, not network addresses.

Answer

Cluster Name

Answer

IP Address

Question 13

Which TWO settings in a DestinationRule are used for load balancing?

Accepted Answer

loadBalancer.simple. TrafficPolicy includes the load balancing settings for a service.

Answer

connectionPool

Answer

outlierDetection

Answer

trafficPolicy.tls

Question 14

Which THREE configuration areas are essential for ensuring observability in a complex Istio mesh?

Accepted Answer

MeshConfig telemetry settings. 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.

Answer

Local sidecar memory limits

Answer

VirtualService timeouts

Question 15

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 16

Which TWO are common causes for a service to be ejected by Outlier Detection?

Accepted Answer

Consecutive gateway failures.. Outlier detection in service meshes (e.g., Istio/Envoy) ejects a host from the load-balancing pool when it exhibits repeated failures at the connection or request level. Option A is correct because consecutive gateway failures—such as TCP connection failures, timeouts, or HTTP 502/503/504 responses classified as gateway errors—trigger the consecutive-gateway-failures ejection policy. Option B is correct because consecutive 5xx responses from the upstream service are counted by the consecutive-5xx ejection policy and cause the endpoint to be ejected once the threshold is exceeded. Options C and E are incorrect because high disk or CPU usage are resource-pressure conditions handled by metrics-based autoscaling or resource limits, not by outlier detection's failure counters. Option D is incorrect because the number of logged-in users is an application-level metric unrelated to the consecutive failure thresholds that outlier detection evaluates.

Answer

High disk usage on the pod.

Answer

Too many users logged in.

Answer

High CPU usage on the pod.

Question 17

Which THREE fields are found in the 'http' connectionPool configuration?

Accepted Answer

idleTimeout. http2MaxRequests, maxRequestsPerConnection, and idleTimeout are valid fields.

Answer

maxConnections

Answer

maxRetries

Question 18

Which THREE of the following are valid ways to control egress traffic in Istio?

Accepted Answer

Sidecar resource with egress policy. Egress control can be achieved via mesh-level configuration, gateway-based routing, or sidecar-level restrictions.

Answer

Kiali Dashboard

Answer

PeerAuthentication

Question 19

Which TWO of the following are valid fields within a DestinationRule's 'trafficPolicy'?

Accepted Answer

connectionPool. In Istio's DestinationRule, the trafficPolicy block supports connectionPool (D), which configures TCP/HTTP connection pool limits such as maxConnections, http1MaxPendingRequests, and http2MaxRequests for the destination workloads, and outlierDetection (E), which defines passive health checking via consecutive5xxErrors, interval, and baseEjectionTime to eject unhealthy endpoints. Both are legitimate subfields of trafficPolicy and are applied per destination (or per subset/port override). By contrast, retryPolicy (A) is a field of a VirtualService's HTTP route, not a DestinationRule trafficPolicy. virtualHosts (B) is a top-level field of a VirtualService (and of Envoy route configuration), not part of DestinationRule. faultInjection (C) is also configured in a VirtualService's HTTP route, not in a DestinationRule trafficPolicy.

Answer

retryPolicy

Answer

virtualHosts

Answer

faultInjection

Question 20

Which TWO components must be configured to allow external traffic to enter the mesh?

Accepted Answer

VirtualService. In Istio, the Gateway resource (option C) is the component that configures the ingress/egress load balancer at the edge of the mesh, binding a port and hosts (e.g., servers: port 80, hosts: "*") so external traffic can reach the mesh. The VirtualService (option B) is required to bind to that Gateway via its gateways field and define the routing rules (match and route) that direct the incoming external requests to the appropriate destination service inside the mesh. Together, Gateway + VirtualService form the standard ingress path: the Gateway opens the door and the VirtualService decides where traffic goes. DestinationRule (A) only defines traffic policies like load balancing, connection pools, and subsets after routing occurs, so it is not required to admit external traffic. PeerAuthentication (D) configures mTLS authentication between workloads and does not expose services externally, and Sidecar (E) scopes sidecar proxy configuration per workload namespace rather than enabling ingress.

Answer

DestinationRule

Answer

PeerAuthentication

Answer

Sidecar