ICA Advanced Scenarios Practice Test 3 — 15 Questions

Question 1

You want to force all traffic to an external service to go through an EgressGateway. What is required?

Accepted Answer

A ServiceEntry for the host and a VirtualService to direct traffic to the egress gateway.. A ServiceEntry to register the external host, and a VirtualService to route that traffic to the EgressGateway.

Answer

Only a ServiceEntry.

Answer

A PeerAuthentication policy.

Answer

Only an EgressGateway.

Question 2

When configuring a Gateway API resource, which TWO properties are defined within the 'listeners' block?

Accepted Answer

Port. In the Gateway API, each entry in the 'listeners' block defines how the gateway accepts traffic, and two of its core required fields are the port and the protocol. Option B (Port) is correct because a listener must specify the network port on which the gateway listens for incoming connections, such as port 80 or 443. Option D (Protocol) is correct because a listener must declare the protocol it handles, such as HTTP, HTTPS, TLS, or TCP, which determines how traffic on that port is processed. The other options do not belong in the 'listeners' block: request retries (A) and circuit breaker policy (C) are traffic-management policies typically expressed in HTTPRoute or backend policy resources, while a service account (E) is a Kubernetes identity object unrelated to listener configuration.

Answer

Request retries

Answer

Circuit breaker policy

Answer

Service account

Question 3

When configuring a multi-cluster mesh, what does a 'ServiceEntry' with 'location: MESH_EXTERNAL' signify?

Accepted Answer

The service is outside the mesh but managed by Istio policies.. It tells Istio that the service is external to the mesh, but it should be treated as a first-class citizen for routing and policy purposes.

Answer

The service is a local cluster service.

Answer

The service does not exist.

Answer

The service is inside the mesh.

Question 4

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 5

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 6

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 7

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 8

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 9

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 10

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 11

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 12

You are running an Istio mesh with several clusters. You need to ensure that all outbound traffic from the mesh to external services is visible and controlled. You have already configured a ServiceEntry for an external API at api.external.com. However, you notice that traffic to this API is not being logged in Kiali and no telemetry is collected. What is the most likely cause?

Accepted Answer

The ServiceEntry is not exported to the namespace where the client pod resides, so the sidecar does not apply the configuration.. ServiceEntry resources are namespace-scoped but can be exported to other namespaces using the exportTo field. If a client pod is in a namespace that does not have access to the ServiceEntry, its sidecar will not have the routing configuration, and traffic to the external service will not be captured or logged. Ensuring proper export settings is crucial for mesh-wide visibility.

Answer

The ServiceEntry is defined in a namespace that does not have the istio-injection=enabled label, so sidecars are not injected.

Answer

The sidecar proxies are not intercepting outbound traffic to external services because the mesh's outboundTrafficPolicy is set to ALLOW_ANY.

Answer

The ServiceEntry is missing the resolution: DNS field, so Istio cannot resolve the external service.

Question 13

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 14

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 15

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.