CCNA Traffic Management Questions

DestinationRule defines traffic policies for a service, including outlier detection, which ejects unhealthy hosts and implements circuit breaking. This satisfies the requirement to prevent cascading failures during high latency by limiting traffic to failing endpoints, unlike VirtualService, which handles routing rules rather than health-based ejection.

Configuring the timeout field enforces the 2-second limit, causing the request to fail immediately once that duration elapses. This directly satisfies the stem's constraint of aborting slow or hanging requests rather than letting them continue indefinitely, which is exactly the behaviour required for the occasionally hanging service.

Without a VirtualService, Istio's sidecar proxies fall back to Envoy's native load-balancing across all endpoints discovered for the service, defaulting to round-robin distribution. No layer-7 traffic rules are applied, so routing remains at layer 4 with equal weighting per healthy endpoint, satisfying the scenario's absence of any defined VirtualService.

Istio splits traffic through VirtualService routing rules, where weighted destinations distribute percentages across subsets. Configuring a 90/10 weight split in the VirtualService's HTTP route satisfies the requirement to send 10% of traffic to the new version.

The Gateway defines the ingress listener on port 443 with TLS termination via tls.mode SIMPLE and a referenced certificate secret, while the VirtualService binds to that Gateway using the gateways field and routes to the internal service on port 80. This is the standard ingress pattern for terminating TLS at the gateway. Both resources are required and must reference each other correctly.

Retry policies are configured in the VirtualService's HTTP route, where the retries block specifies attempts, perTryTimeout and retryOn conditions. This satisfies automatic retrying of failed requests, including 503 responses, before returning an error to the caller.

VirtualService HTTP route rules carry a timeout field that caps the total duration of a request to the destination, so setting it to 5s enforces the limit. DestinationRule governs connection pooling and outlier detection, not request timeouts.

The subsets field in a DestinationRule groups endpoints by label, typically the version label, enabling traffic policies and routing to target distinct service versions. It satisfies the versioning requirement because VirtualService routing rules reference these named subsets to split traffic.

`istioctl analyze` performs static analysis of Istio configuration, checking YAML resources and live cluster state against known validation rules. It surfaces misconfigurations such as conflicting virtual services, missing gateways, or invalid selectors before they cause runtime failures, satisfying the need to identify configuration issues proactively rather than debugging symptoms after deployment.

ROUND_ROBIN is Istio's default load balancing algorithm, distributing requests sequentially across healthy endpoints in each locality. This satisfies the stem's constraint of identifying the out-of-the-box behaviour, requiring no DestinationRule traffic policy override. Other algorithms such as LEAST_REQUEST, RANDOM and PASSTHROUGH demand explicit configuration.

connectionPool sits within DestinationRule trafficPolicy and defines TCP or HTTP connection limits to an upstream service, including maxConnections, http1MaxPendingRequests and http2MaxRequests. It satisfies the question by being one of the traffic policy fields governing how connections are managed.

PeerAuthentication enforces mutual TLS between sidecars, encrypting all service-to-service traffic inside the mesh. This directly satisfies the stem's requirement for securing intra-mesh traffic, since Istio's data plane authenticates both ends of every connection using workload identities issued by the mesh's certificate authority.

Kiali is the Istio console that renders the service mesh topology and traffic-management rules graphically, satisfying the stem's GUI visualisation requirement. It reads Istio configuration directly, showing virtual services, destination rules and their routing relationships.

Mirroring duplicates each live request and dispatches the copy to a shadow destination alongside the primary service. The primary response still returns to the caller, so the test service receives realistic production traffic without affecting users, enabling safe validation before promotion.

The redirect field in the VirtualService rewrites the request's URI and authority, sending traffic to a different destination than the original request. It satisfies the requirement to redirect traffic to a different URI without altering the client.

The selector field is mandatory because it defines which pods the Gateway's configuration applies to, using label matching. Without it, the Gateway resource cannot bind to any workload, so Istio rejects the manifest during validation.

A route to a service with no matching pods yields a 503 Service Unavailable, because Istio's Envoy sidecars have no healthy upstream endpoints to load-balance to. The VirtualService route resolves, but the destination host's endpoint list is empty, so requests fail at the data plane rather than returning 404.

`istioctl proxy-config` queries a specific Envoy's live xDS state, dumping listeners, clusters, routes and endpoints as actually applied. This satisfies the stem's requirement for the effective configuration of one named proxy, rather than the mesh-wide desired state that `istioctl analyze` or the IstioOperator spec would show.