Select Two (Multi-Select) Questions

baseEjectionTime

Why it fails: Affects length, not sensitivity.

minHealthPercent

Why it fails: Safeguard for overall health.

maxEjectionPercent

Why it fails: Doesn't change sensitivity.

istioctl delete pod

Why it fails: istioctl delete pod is not a subcommand; deletion is performed with kubectl, not istioctl. It is tempting because restarting a problematic pod often clears proxy issues, but istioctl exposes no delete verb. It would be correct if the task were removing a resource via kubectl.

istioctl monitor

Why it fails: istioctl monitor is not a valid subcommand; mesh health inspection uses analyse, proxy-status, proxy-config and describe. It is tempting because a monitoring-sounding verb appears plausible, but no such command exists. It would be correct only if Istio shipped a monitor subcommand, which it does not.

istioctl update mesh

Why it fails: The istioctl CLI exposes diagnostics such as proxy-status, analyse and proxy-config; there is no update mesh subcommand, so this cannot debug health. It is tempting because mesh-wide configuration changes are a real istioctl capability, but those are applied through istioctl install or upgrade, not update mesh.

Global MeshConfig 'proxyMetadata' settings

Why it fails: proxyMetadata supplies bootstrap environment variables to sidecar proxies, such as tracing or DNS capture settings; it does not decide whether traffic is accepted. Acceptance depends on PeerAuthentication, AuthorizationPolicy and workload enrolment. proxyMetadata suits tuning proxy behaviour, not authorising or rejecting inbound requests.

Kubernetes Service Port definition

Why it fails: The Kubernetes Service port defines which container port receives traffic inside the cluster, but mesh acceptance is governed by Istio resources: PeerAuthentication mTLS mode, AuthorizationPolicy rules and sidecar or ambient enrolment. Service ports matter for plain Kubernetes routing without a mesh enforcing identity-based policy.

Gateway

Why it fails: A Gateway secures ingress and egress at the mesh boundary, not pod-to-pod traffic inside it. It is the right choice for exposing services externally with TLS termination, but the question asks which mechanisms secure traffic between workloads within the mesh.

VirtualService

Why it fails: VirtualService configures routing, retries and traffic splitting for requests, not the cryptographic identity or encryption of mesh traffic. It is correct when you need to shape or direct traffic, but peer authentication and mTLS between sidecars are handled elsewhere.

ServiceEntry

Why it fails: ServiceEntry registers external hosts in the mesh registry so internal workloads can reach them; it does not secure traffic. It is the right choice when onboarding third-party APIs, but it neither encrypts nor authenticates connections between mesh workloads.

subsets

Why it fails: Subsets are not a Gateway configuration element; they belong to API products, where they partition a product's operations. It is tempting because subsets appear alongside Gateway-related settings in API management tooling, but they would be correct when defining which operations an API product exposes, not when configuring a Gateway.

retry

Why it fails: Retry is a resilience policy governing repeated request attempts, not a Gateway listener, route, or service configuration, so it cannot appear as a valid Gateway setting. It is tempting because retry policies are configured on gateways in service meshes, but that belongs to traffic policy, not the Gateway resource's configuration fields.

endpoints

Why it fails: Endpoints are not a Gateway configuration element; they belong to API proxies, defining the target servers a proxy routes to. It is tempting because endpoints appear in the same API management interface, but they would be correct when configuring where a proxy sends traffic, not when configuring a Gateway.

subsets

Why it fails: subsets is not a Gateway field at all; it belongs to a DestinationRule, where it groups workload labels into named subsets for traffic policies. It is tempting because gateways route to subsets, but the Gateway resource itself requires only selector and servers to define which proxies and listeners apply.

tls

Why it fails: tls is an optional server setting inside a Gateway's servers block, used to terminate or pass through TLS; a plain HTTP listener omits it entirely. It is tempting because most production gateways do serve HTTPS, but the mandatory fields are selector and servers, not tls.

hosts

Why it fails: hosts is optional in a Gateway resource, used to match incoming request hostnames for routing; omitting it leaves the gateway listening on all hosts. It is tempting because host-based routing is common in production, but the mandatory fields are the gateway's listeners and its selector, not hosts.

Kubernetes node IP addresses

Why it fails: Kiali's Graph view renders service-to-service traffic topology, showing nodes, edges, request rates and health between workloads. Kubernetes node IP addresses belong to cluster infrastructure and appear in node or infrastructure views, not in the application traffic graph, which maps Envoy-observed communication rather than host addressing.

Sidecar image versions

Why it fails: The Graph view displays traffic metrics between mesh workloads, not container image metadata. Sidecar image versions are visible through pod inspection or workload details, so this option misplaces deployment configuration into a topology visualisation that is driven by Envoy telemetry rather than image tags.

User login history

Why it fails: Kiali visualises Istio service mesh telemetry — request rates, error percentages, latency and mTLS status between workloads. User login history is authentication audit data held by an identity provider such as Microsoft Entra ID, and is never surfaced by the mesh graph, which tracks service traffic rather than human sessions.

Disabling mTLS for performance

Why it fails: Disabling mTLS removes workload identity and encryption, breaking zero-trust authentication between clusters and preventing secure cross-cluster service calls. mTLS must remain enabled for multi-cluster trust. Disabling it is tempting when troubleshooting handshake or certificate errors, but that masks the fault rather than fixing it.

Using a single ingress gateway for all traffic

Why it fails: One ingress gateway is a single point of failure and a single failure domain, so losing its cluster or control plane severs all north-south traffic. Multiple gateways per cluster are the recommended pattern; a single gateway suits simple single-cluster deployments where cross-cluster failover is not required.

grpc

Why it fails: The connectionPool block configures TCP settings: maxConnections, http1MaxPendingRequests, http2MaxRequests, idleTimeout and tcp keepalive. gRPC is a protocol served through the port or protocol fields, not a connectionPool setting, though gRPC traffic does traverse the pool.

tls

Why it fails: TLS settings sit under the top-level trafficPolicy, not connectionPool, which only covers connection limits such as tcp, http, and http2. It tempts because DestinationRule does configure TLS, but via trafficPolicy.tls, making it correct for mutual TLS to upstream services.

retry

Why it fails: Retry is a traffic-management policy configured under HTTP route or virtual service settings, not a fault injection type. It is tempting because both features manipulate request handling. Istio's fault injection types are delay and abort, which inject latency or HTTP errors into selected traffic.

timeout

Why it fails: Istio's fault injection supports delays and aborts; timeout is configured via a route rule's timeout field, not as an injected fault type. It is tempting because timeouts relate to resilience testing, but that scenario uses VirtualService timeout settings rather than the fault.abort or fault.delay blocks.

redirect

Why it fails: Istio injects faults only as delays or aborts; redirect is an HTTPRoute destination action, not a fault type. It is tempting because redirects alter traffic flow, but that belongs in a route's redirect configuration, whereas fault injection deliberately returns errors or latency to the caller.

requestRetryCount

Why it fails: requestRetryCount is not part of outlierDetection; retry behaviour is configured under the HTTP route's retries policy with retryOn, attempts and perTryTimeout. Outlier detection ejects unhealthy endpoints via consecutive5xxErrors, interval and baseEjectionTime. Retry counts govern request replay, not endpoint ejection.

maxConnectionTimeout

Why it fails: maxConnectionTimeout is not a field within outlierDetection; that block contains consecutive5xxErrors, interval, baseEjectionTime, maxEjectionPercent and splitExternalLocalOriginErrors. It is tempting because connection-pool settings such as maxConnections and connectionTimeout sit in the same DestinationRule, but those belong under trafficPolicy's connectionPool, not outlier detection.

Cluster Name

Why it fails: An Istio SPIFFE ID is the trust domain plus the workload's Kubernetes service account namespace and name; cluster name is not a component. It is tempting because clusters often map to trust domains, and would be correct if the identity scheme were built on cluster-scoped rather than namespace-scoped workload identity.

IP Address

Why it fails: The SPIFFE ID encodes trust domain, workload path and service name; an IP address is not a component, since SPIFFE deliberately decouples identity from network location so workloads remain identifiable across dynamic addressing. IP addresses appear in certificate SANs for other schemes, which makes this tempting, but Istio's SPIFFE URI never includes them.

connectionPool

Why it fails: This is for connection management.

outlierDetection

Why it fails: This is for health monitoring, not load balancing algorithms.

trafficPolicy.tls

Why it fails: This handles encryption.

Local sidecar memory limits

Why it fails: Sidecar memory limits are a resource-management setting that prevents OOM kills; they emit no telemetry, so they contribute nothing to mesh observability. It is tempting because resource constraints do affect whether proxies stay healthy, and would be correct when tuning sidecar stability rather than tracing, metrics and logging.

VirtualService timeouts

Why it fails: VirtualService timeouts control request deadlines and retry behaviour, shaping traffic rather than exposing telemetry, so they add no observability data. It is tempting because timeout and retry metrics do surface in dashboards, and would be correct for resilience tuning, but observability requires tracing, metrics collection and access logging.

scale

Why it fails: K8s function.

filter

Why it fails: Filtering inspects or drops traffic by attribute; it does not transform a request, so it cannot be a VirtualService action. It is tempting because filters appear in gateway and Envoy HTTP connection manager configuration, where they are the correct mechanism for access control or header manipulation rather than routing actions.

replicate

Why it fails: K8s function.

High disk usage on the pod.

Why it fails: Outlier Detection ejects on consecutive 5xx errors or gateway failures, not disk utilisation; storage pressure does not feed its success-rate calculation. High disk usage is tempting as a health signal, but would be the correct trigger for volume expansion or eviction by kubelet disk-pressure taints.

Too many users logged in.

Why it fails: Not a mesh metric.

High CPU usage on the pod.

Why it fails: Outlier Detection ejects hosts based on consecutive gateway failures or HTTP 5xx responses, not resource consumption metrics. High CPU is tempting because it suggests an unhealthy pod, but would be the correct trigger for horizontal pod autoscaling or resource-limit tuning instead.

maxConnections

Why it fails: maxConnections belongs to the JMS connection pool, not the HTTP connection pool, so it fails this scenario. It is tempting because connection limits genuinely matter for JMS throughput tuning, where maxConnections would be the correct field to configure.

maxRetries

Why it fails: maxRetries governs retry behaviour on outbound HTTP calls, not connection pool sizing, so it does not belong in the 'http' connectionPool block. It is tempting because retry counts are configured under HTTP settings, making it the right field for resilience tuning.

Kiali Dashboard

Why it fails: Kiali is an observability console for visualising service mesh topology, traffic and configuration health; it does not intercept or filter outbound requests. Egress control requires Sidecar, ServiceEntry, Gateway or egress policies. Kiali is the right tool for diagnosing mesh behaviour, not for enforcing egress rules.

PeerAuthentication

Why it fails: PeerAuthentication configures mutual TLS and workload identity verification between mesh peers; it does not govern traffic leaving the mesh. Egress control needs Sidecar, ServiceEntry, Gateway or egress access policies. PeerAuthentication is correct when securing service-to-service authentication inside the mesh, not for outbound traffic.

retryPolicy

Why it fails: retryPolicy is a field of the VirtualService HTTP route, defining attempts, perTryTimeout and retryOn conditions; DestinationRule trafficPolicy has no retryPolicy field. It is tempting because retries are traffic-management behaviour, but they are configured on the route, not the destination.

virtualHosts

Why it fails: virtualHosts belongs to the VirtualService spec, where it maps hostnames to routing rules, not to DestinationRule trafficPolicy. It is tempting because both resources shape traffic, but DestinationRule trafficPolicy governs connection pooling, load balancing and outlier detection for a host.

faultInjection

Why it fails: faultInjection is configured under VirtualService HTTP routes to inject delays or aborts; DestinationRule trafficPolicy does not expose it. It is tempting because both are Istio traffic features, but fault injection manipulates request handling at the route level, not the destination's connection policy.

DestinationRule

Why it fails: DestinationRule defines traffic policy after routing, such as load-balancing and connection pool settings, for traffic already inside the mesh. It is tempting because it is a core traffic-management resource configured alongside gateways, but it cannot admit external connections; ingress needs a Gateway listener on the edge plus a VirtualService binding hosts and routes to internal services.

PeerAuthentication

Why it fails: PeerAuthentication configures mutual TLS acceptance between workloads inside the mesh; it governs authentication of existing peers, not admission of external connections. It is tempting because it is a security resource commonly paired with gateways, but external entry requires a Gateway exposing the port plus a VirtualService routing that traffic to the target service.

Sidecar

Why it fails: A sidecar proxies traffic for one workload's pods; it cannot accept connections arriving from outside the mesh. It is tempting because sidecars carry all in-mesh traffic and are configured alongside ingress, but exposing external traffic requires a Gateway resource bound to the mesh's ingress gateway, plus a VirtualService routing to the internal service.