ICA Practice Test 15 — 15 Questions

Question 1

If you set 'mode: PERMISSIVE' in PeerAuthentication, what does this allow?

Accepted Answer

It allows both mTLS and plaintext.. PERMISSIVE mode allows both mTLS and plaintext traffic to coexist, which is ideal for migrations.

Answer

It requires plaintext only.

Answer

It requires mTLS only.

Answer

It disables all security.

Question 2

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

Question 3

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 4

What is the purpose of the 'istio-sidecar-injector' service in the Istio control plane?

Accepted Answer

To inject the Envoy proxy sidecar into pods. The sidecar injector is a MutatingAdmissionWebhook that intercepts pod creation requests to inject the proxy container.

Answer

To act as a load balancer for traffic

Answer

To monitor the health of pods

Answer

To store mesh configuration data

Question 5

Where do you configure the hostnames that a Gateway should accept?

Accepted Answer

Gateway. The Gateway resource in Istio is where you declare the hosts (and ports/protocols) that the ingress or egress gateway should accept traffic for. The 'hosts' field under 'servers' specifies which SNI/Host headers are allowed. VirtualService then binds routes to that gateway, but the host acceptance list lives on the Gateway itself.

Answer

DestinationRule

Answer

ServiceEntry

Answer

VirtualService

Question 6

Which command helps troubleshoot configuration issues by analyzing the cluster for errors?

Accepted Answer

istioctl analyze. istioctl analyze scans for common misconfigurations in the cluster.

Answer

istioctl debug

Answer

istioctl check

Answer

kubectl describe

Question 7

Which of the following describes the difference between Circuit Breaking and Outlier Detection?

Accepted Answer

Circuit Breaking monitors request load, Outlier Detection monitors host health.. Circuit Breaking monitors request load (e.g., connection pool saturation, pending requests, retries) and trips when thresholds are exceeded, preventing cascading failures by rejecting new requests. Outlier Detection monitors host health by passively tracking errors (e.g., 5xx responses) and ejecting unhealthy hosts from the load balancing pool. Thus, the correct distinction is that Circuit Breaking focuses on request load, while Outlier Detection focuses on host health.

Answer

Circuit Breaking is for ingress, Outlier Detection is for egress.

Answer

Circuit Breaking is proactive, Outlier Detection is reactive.

Answer

Outlier Detection is for connection pooling.

Answer

Circuit Breaking only works on TCP.

Question 8

Which THREE features are supported by the Istio 'trafficPolicy' in a DestinationRule?

Accepted Answer

Connection pooling. In an Istio DestinationRule, the trafficPolicy field supports connection pooling (A) via the connectionPool settings that control TCP and HTTP connection limits, timeouts, and keepalive behavior for the destination. Outlier detection (B) is also part of trafficPolicy, configured under outlierDetection, and enables passive health checking by ejecting unhealthy hosts from the load-balancing pool. Load balancing (D) is supported through the loadBalancer field within trafficPolicy, allowing selection of algorithms such as ROUND_ROBIN, LEAST_REQUEST, RANDOM, or PASSTHROUGH. Traffic mirroring (C) and fault injection (E) are not configured in DestinationRule trafficPolicy; they are defined in a VirtualService, where mirroring uses the mirror field and fault injection uses the faults field.

Answer

Traffic mirroring

Answer

Fault injection

Question 9

Which TWO fields in the IstioOperator CR are commonly used to configure ingress gateway resources?

Accepted Answer

spec.components.ingressGateways. Option B, spec.components.ingressGateways, is correct because the IstioOperator CR exposes the ingress gateway as a component under spec.components, where you can set fields like enabled, k8s (resources, replicaCount, hpaSpec, service), and name to configure the gateway's Kubernetes deployment and resources. Option C, spec.values.gateways.istio-ingressgateway, is correct because the IstioOperator passes Helm-style values through spec.values, and the istio-ingressgateway key under gateways is the standard location to override gateway settings such as resources, autoscaling, and service ports. Option A is not a valid IstioOperator path, since gateways are configured under spec.components or spec.values rather than a top-level spec.gateways.enabled field. Option D is incorrect because spec.pilot configures the istiod control plane, not ingress gateway resources. Option E is incorrect because spec.meshConfig controls mesh-wide behavior such as access logging and default config, not ingress gateway resource settings.

Answer

spec.gateways.enabled

Answer

spec.pilot.gateways

Answer

spec.meshConfig.ingress

Question 10

A team wants to perform a canary deployment by shifting 10% of traffic to a new version of their service. Which resource allows this weighting?

Accepted Answer

VirtualService. VirtualService uses the weight field in the route block to distribute traffic percentages.

Answer

Sidecar

Answer

DestinationRule

Answer

Gateway

Question 11

Which field in the AuthorizationPolicy is used to restrict access based on the verified JWT claims?

Accepted Answer

rules.when. The `rules.when` field in an Istio AuthorizationPolicy is specifically designed to define conditions that must be met for a request to be allowed. It supports a variety of condition keys, including `request.auth.claims`, which allows you to match against verified JWT claims. This is the correct mechanism to restrict access based on JWT claims because it evaluates the claims after the JWT has been validated by Istio's authentication policy.

Answer

rules.from.principals

Answer

rules.to.operation.methods

Answer

rules.from.source.namespaces

Question 12

Which THREE fields in an AuthorizationPolicy are evaluated under the 'rules' section?

Accepted Answer

from. In an Istio AuthorizationPolicy, the 'rules' section defines the conditions under which the policy applies, and each rule can contain the fields 'from', 'to', and 'when'. Option C ('from') is correct because it specifies the source of the request, such as a source principal, namespace, or IP block, and is evaluated as part of the rule matching. Option E ('to') is correct because it defines the destination attributes of the request, including operation methods, paths, and ports, which are matched within the rule. Option D ('when') is correct because it provides additional custom conditions using Istio attributes (e.g., request.headers, source.ip) that must be satisfied for the rule to match. Option A ('action') is not part of the 'rules' section; it is a top-level field of the AuthorizationPolicy that specifies ALLOW, DENY, AUDIT, or CUSTOM. Option B ('selector') is also not part of the 'rules' section; it is a top-level field used to target specific workloads by label.

Answer

action

Answer

selector

Question 13

Which resource is used to define the root certificate for a custom CA?

Accepted Answer

cacerts. The 'cacerts' secret in the 'istio-system' namespace is used to provide custom root certificates.

Answer

istio-ca-secret

Answer

root-secret

Answer

istio-root-ca

Question 14

Which THREE configurations affect the way traffic is distributed across pods?

Accepted Answer

Load balancer policy. In Istio traffic management, the load balancer policy (option A) directly controls how requests are distributed across the healthy endpoints of a service — for example ROUND_ROBIN, LEAST_REQUEST, RANDOM, or PASSTHROUGH — so it is a core determinant of pod traffic distribution. Traffic weight (option B) is used in VirtualService route rules to split a percentage of requests between destination subsets, which changes how much traffic each group of pods receives. Subset definitions (option C) group pods by labels (e.g., version: v1 vs v2) and are the targets that weights and route rules reference, so they shape which pods participate in the distribution. Gateway port (option D) only defines the ingress listener port on the gateway and does not influence how traffic is balanced across pods. Retry policy (option E) governs how failed requests are retried, not how the initial traffic is distributed among pod endpoints.

Answer

Gateway port

Answer

Retry policy

Question 15

Which THREE are valid load balancing policies in Istio?

Accepted Answer

RANDOM. Istio's DestinationRule trafficPolicy.loadBalancer.simple field supports a fixed set of algorithms, and RANDOM (B), LEAST_CONN (C), and ROUND_ROBIN (E) are all valid values in that enum, so each is a legitimate load balancing policy. RANDOM (B) picks a random healthy endpoint, LEAST_CONN (C) selects the endpoint with the fewest active connections, and ROUND_ROBIN (E) cycles through endpoints in order. FAILOVER (A) is not an Istio load balancing policy; failover behavior is handled through outlier detection and locality/priority settings rather than a load balancer type. STICKY (D) is also not a valid value; session affinity in Istio is configured separately via consistent hash-based load balancing (e.g., HTTP cookie, header, or source IP), not as a simple policy named STICKY.

Answer

FAILOVER

Answer

STICKY