CCNA Advanced Scenarios Questions

HTTPRoute attaches to a Gateway and defines path-prefix matching rules, satisfying the requirement for path-based routing. Unlike TCPRoute, which operates at layer 4 without HTTP awareness, HTTPRoute provides layer 7 host, header and path matching. Istio's Gateway API implementation reconciles HTTPRoute resources to configure Envoy route configurations.

Gateway defines the listener configuration and ports that expose the mesh to inbound traffic, satisfying the requirement for a dedicated entry point. It binds to a GatewayClass and routes requests onward via HTTPRoute resources, separating infrastructure-level ingress from application routing rules.

A ServiceEntry with location MESH_EXTERNAL registers an external endpoint so Istio's traffic policies, mTLS origination and telemetry still govern egress calls, satisfying the stem's multi-cluster requirement that services outside the mesh remain manageable by Istio rather than bypassing the sidecar entirely.

MeshConfig telemetry settings control whether Envoy proxies generate metrics, access logs and traces mesh-wide. Enabling these settings is essential because without them the control plane collects no telemetry, leaving the mesh effectively unobservable regardless of other configuration.

A ServiceEntry registers api.example.com in the mesh's internal service registry so the sidecar has a route and can allow the connection. Setting the Sidecar's outboundTrafficPolicy to REGISTRY_ONLY restricts egress to only services present in the registry, so every other unknown host stays blocked. This is the supported way to selectively permit external hosts without opening the mesh to all destinations.

PeerAuthentication governs mutual TLS enforcement between workloads, so a STRICT policy in either namespace can reject plaintext traffic from the other service. Checking it confirms whether mTLS mode blocks the cross-namespace connection, satisfying the requirement to verify connectivity across namespace boundaries.

A Gateway resource with TLS mode MUTUAL enables mutual TLS termination at the ingress gateway. The credentialName must reference a Kubernetes secret containing the server certificate, private key, and CA certificate. This enforces client certificate validation for external clients connecting to the public gateway, while the private gateway remains unchanged because the Gateway resource is applied only to the public gateway's selector.

proxy-status shows whether each proxy is in sync with istiod, ruling out stale configuration. Then proxy-config listeners and routes on the specific client pod reveal whether the expected listener exists for the destination port and whether a route matches the destination host. This sequence directly inspects the running proxy's state, which is exactly what the troubleshooting scenario requires.

The istio-remote-secret stores the remote cluster's API server credentials, enabling the shared control plane to authenticate and manage that cluster's services and endpoints. This satisfies the multi-cluster requirement by granting the primary control plane secure access to remote API servers for service discovery and configuration propagation.

Defines the simple load balancing algorithm (e.g., ROUND_ROBIN).

Envoy increments upstream_rq_timeout each time a request to an upstream cluster exceeds the configured timeout before a response arrives. It counts timed-out upstream requests specifically, distinguishing them from connection failures or resets, which are tracked by separate counters.

A Sidecar resource with an egress policy applies host-level and port-level rules to outbound traffic from selected workloads, restricting which external services pods may reach. This satisfies the egress control requirement by enforcing allowlists at the sidecar proxy.

Each entry in the listeners block must specify the port the listener binds to on the Gateway, alongside its protocol. This port determines which traffic the listener accepts, satisfying the requirement that listeners define the network endpoint for incoming connections.

Kiali renders red edges when the destination workload reports elevated error responses or when an Istio authorisation or traffic policy rejects requests. This colouring reflects the measured error rate on that edge, not latency or throughput, so it points to failures or policy blocks.

A VirtualService allows you to define HTTP routes that match on request attributes such as headers, and then route to different destinations with weights. You can create a route that matches a specific header (e.g., user: test) and directs to the new version, and another route with a weight-based split (90/10) for all other traffic. This achieves both the canary rollout and the sticky routing for the test user.

Outlier detection actively ejects endpoints that return consecutive errors from the load balancing pool for a defined interval, then returns them for re-evaluation. This satisfies the stem's requirement by isolating unhealthy hosts, preventing failed requests from reaching them while other healthy endpoints continue serving traffic.

The Telemetry API is the supported, declarative way to configure metrics, access logging, and tracing for workloads in a mesh. It supports defining providers, including OpenTelemetry, and selecting which workloads emit which signals. Because it is applied through Istio configuration rather than application changes, it meets the goal of exporting telemetry to a central platform without touching the app or redeploying it.

Envoy sidecar proxies are deployed alongside each service instance and intercept all inbound and outbound traffic. They generate a rich set of metrics, including request counts, response codes (like 5xx), and latency. These metrics are exposed on the sidecar's Prometheus endpoint and scraped by Prometheus. Therefore, the sidecar is directly responsible for generating the 5xx error metrics for a service.

istioctl proxy-config reads the sidecar's live Envoy configuration directly from the proxy, showing clusters, listeners, routes and endpoints. It satisfies the constraint of verifying pushed configuration without Kiali, querying the data plane rather than relying on the dashboard.

PeerAuthentication defines the mutual TLS mode Istio applies to workloads in a namespace or mesh, satisfying the requirement to control service-to-service encryption. Its mtls.mode field accepts STRICT, PERMISSIVE or DISABLE, governing whether sidecars accept plaintext alongside encrypted traffic. This makes it the resource for configuring workload mTLS behaviour.

A ServiceEntry registers the external host in the mesh registry, while a VirtualService routes matching traffic to the egress gateway. Together they satisfy the requirement that all outbound traffic to that external service passes through the EgressGateway.

DestinationRule is where trafficPolicy defines connectionPool limits and outlierDetection for a destination. To confirm what the proxy actually enforces, istioctl proxy-config cluster shows the Envoy cluster's circuit breaker and outlier detection fields derived from that resource. This combination directly answers which settings are active and is the standard diagnostic path for suspected breaker trips.

`istioctl analyze` inspects live cluster configuration and reports misconfigurations, such as conflicting virtual services or missing sidecars, that degrade mesh health. It satisfies the debugging constraint by surfacing actionable diagnostics without requiring traffic capture, unlike proxy-level tools such as `istioctl proxy-config`.

istiod is the control plane's unified binary; it runs the Pilot component, which watches Kubernetes services and Istio configuration, then generates and pushes the xDS configuration (CDS, EDS, LDS, RDS) to Envoy sidecars. No other component performs this translation.

The proxy-config cluster command with the -o json flag outputs the full cluster configuration in JSON format. This includes the outlier detection settings, which are part of the cluster's configuration. By examining the JSON output, you can verify the exact outlier detection parameters applied to the cluster, such as consecutive errors, interval, and ejection percentages. This is the most direct way to inspect those settings.

Locality-aware load balancing prioritises endpoints within the same zone or region, so requests avoid crossing availability-zone boundaries. This directly reduces round-trip latency and cuts cross-zone egress charges, satisfying the stem's requirement for the main advantage over default round-robin distribution across all healthy endpoints.

VirtualService resources in Istio route traffic by matching request attributes and splitting weights across destination subsets, enabling controlled traffic shifting between two service versions. This satisfies the stem's requirement for gradual, percentage-based canary rollouts without redeploying workloads.

ServiceEntry resources have an exportTo field that controls which namespaces can see them. By default, they are exported to all namespaces (exportTo: *), but if it is set to a specific namespace or '.', only that namespace can use it. If the client pod is in a different namespace and the ServiceEntry is not exported there, the sidecar will not have the necessary configuration to route and collect telemetry for that external service, resulting in no logs or metrics.

The Sidecar resource scopes a workload's proxy to a defined set of namespaces and services, limiting which registries and endpoints it receives. This directly satisfies the multi-tenancy constraint by preventing cross-namespace visibility, unlike PeerAuthentication or AuthorizationPolicy, which govern mTLS and access rather than discovery scope.

The Graph view decorates each node and edge with health indicators, colouring them red or orange when error rates or warning conditions appear. This satisfies the requirement to surface operational state, letting operators spot degraded services directly on the topology rather than correlating separate metric dashboards.

Locality-aware load balancing keeps requests within the same region or zone where possible, cutting cross-cluster latency and avoiding failure domains. This directly satisfies the stem's high-availability goal by reducing dependence on any single cluster's network path.

Istiod acts as the control plane's configuration translator: it watches Gateway resources, merges them with VirtualService routing, and pushes the resulting Envoy listener, route and cluster configuration to the sidecars and ingress gateways via xDS. Without istiod, the Gateway spec would never become proxy config.