Hard Difficulty 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.

A ServiceEntry with 'resolution: DNS'.

Why it fails: ServiceEntry registers external hosts into the mesh registry so sidecars can route to them; it carries no certificate or trust configuration. It is the correct resource when you need to reach services outside the mesh, not for securing east-west traffic between two primary clusters.

An AuthorizationPolicy allowing all traffic.

Why it fails: AuthorizationPolicy governs whether requests are permitted or denied at the sidecar; it does not provision the certificates or trust bundles that establish mTLS between clusters. It would be the right resource for enforcing access rules on workloads once mutual TLS is already configured.

An EgressGateway with TLS origination.

Why it fails: An EgressGateway with TLS origination terminates and re-originates TLS for traffic leaving the mesh toward external destinations. Multi-primary cluster-to-cluster mTLS relies on shared trust roots and remote secrets, not on an egress gateway terminating connections.

Use 'istioctl install --revision 1-19' on the namespace

Why it fails: 'istioctl install --revision 1-19' installs or upgrades the control plane revision itself; it does not migrate a namespace's workloads. It is tempting because revision flags appear in both tasks, but namespace migration requires relabelling 'istio.io/rev=1-19' so injection selects the new control plane. Installation alone leaves the namespace on 1-18.

Update label and run 'istioctl proxy-config rev 1-19'

Why it fails: 'istioctl proxy-config rev 1-19' is not a valid subcommand; proxy-config inspects Envoy configuration on a specific pod, and no 'rev' operation exists. It is tempting because it mentions the target revision, but it neither changes labels nor restarts workloads. Migration requires relabelling the namespace and restarting deployments for reinjection.

Just update the label; Istio handles it automatically

Why it fails: Relabelling alone does not migrate running workloads; existing pods retain their injected 1-18 sidecars until restarted, so traffic still flows through the old control plane. It is tempting because labels drive injection, but Istio does not automatically restart pods. The correct procedure relabels and then restarts deployments to trigger reinjection.

VirtualService

Why it fails: VirtualService governs routing of traffic that has already been admitted by a listener, matching on headers, paths and weights. It is tempting because it controls traffic flow, yet the stem's block occurs before routing: the Gateway listener's hosts, port and TLS settings determine whether a connection is permitted at all.

DestinationRule

Why it fails: DestinationRule governs post-routing traffic policy — load-balancing, connection pools and outlier detection — not admission at the gateway. It is tempting because it shapes how traffic reaches a service, but the stem's blocked connection is decided by host, port and TLS matching in the Gateway's listener configuration.

Gateway

Why it fails: The Gateway forwards traffic but does not itself grant permission; policy enforcement is governed by the security rulebase applied to that traffic. The Gateway is tempting because it is the visible path component, and it would be the answer if the question concerned routing or connectivity rather than authorisation.

The pod is missing a sidecar.

Why it fails: RequestAuthentication is enforced by the sidecar proxy; without an injected sidecar, no Envoy intercepts the request, so the policy never runs. Sidecar injection is the prerequisite for any Istio authentication or authorisation policy to take effect.

The namespace is missing.

Why it fails: RequestAuthentication policies are namespace-scoped resources; a missing namespace prevents the policy from being created or applied, so no JWT validation occurs regardless of issuer. The namespace is where the policy and its workloads must coexist.

The JWT is too long.

Why it fails: JWT length is not a standard failure mode.

ServiceEntry

Why it fails: A ServiceEntry registers external services into the mesh registry, controlling DNS and egress, not internal request routing. It is tempting when services sit outside the mesh, but header-based routing to an internal service requires a VirtualService match on the x-user-type header.

DestinationRule subset

Why it fails: A DestinationRule subset defines named groups of pods by labels, but it cannot match on request headers. Subsets are tempting because they are the routing targets, yet the header match itself must be declared in a VirtualService, which then references the subset.

Gateway host

Why it fails: A Gateway host defines the ingress listener's servers and ports, not request routing rules. It is tempting because gateways handle inbound traffic, but header-based routing belongs in a VirtualService, which matches on HTTP headers and directs traffic to subsets.

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.

It only works with TCP services.

Why it fails: Works with HTTP and GRPC as well.

It can be configured in a VirtualService.

Why it fails: It must be in a DestinationRule.

It is used to rate limit traffic.

Why it fails: That is a circuit breaker function.

It requires an external monitoring tool.

Why it fails: It is handled by the data plane proxy.

EnvoyFilter for mTLS

Why it fails: DestinationRule is the preferred way for TLS config.

AuthorizationPolicy

Why it fails: AuthorizationPolicy is not required for egress TLS.

The 'tcp-metadata' filter.

Why it fails: This filter adds metadata and is not typically associated with data buffering.

The 'outlier-detection' settings.

Why it fails: Outlier detection focuses on removing unhealthy hosts.

The 'circuit-breaker' settings.

Why it fails: Circuit breaking limits concurrency but does not buffer data.

The ingress gateway has too many listeners.

Why it fails: Gateways are separate from sidecars; this wouldn't OOM the sidecar.

The Kubernetes node is under-provisioned.

Why it fails: While possible, the most likely Istio-specific cause is the scope of service discovery.

The MTU size is too small.

Why it fails: MTU affects packet fragmentation, not proxy memory.

trafficPolicy.outlierDetection.maxRequests

Why it fails: Outlier detection does not contain this field.

trafficPolicy.connectionPool.http.http2MaxRequests

Why it fails: This is specific to HTTP/2.

trafficPolicy.circuitBreaker.maxRequests

Why it fails: CircuitBreaker object does not contain maxRequests.

trafficPolicy.connectionPool.tcp.maxConnections

Why it fails: This limits TCP connections, not request concurrency.

Only 'principals' is valid.

Why it fails: Both are used in different contexts.

Only 'source.principals' is valid.

Why it fails: The field name is 'principals' inside the 'source' object.

They refer to different concepts.

Why it fails: They are consistent in Istio.

Use the 'principals' field.

Why it fails: The principals field matches peer identities from mTLS certificates, such as SPIFFE service account names, not JWT claim values. It is tempting because principals express authenticated identity, and would be correct for mTLS-based workload authorisation. JWT claim mapping instead uses the when condition with request.auth.claims.

Use the 'from' field in the 'source' object.

Why it fails: The source.from field matches request origin attributes such as IP blocks, namespaces and service accounts, not JWT claim values. It is tempting because source scoping looks like identity matching, and would be correct for restricting which workloads may call a service. Custom claims belong in the when condition.

Use an 'EnvoyFilter' because AuthorizationPolicy does not support claims.

Why it fails: EnvoyFilter patches Envoy configuration directly, bypassing Istio's authorisation API; it is not required because AuthorizationPolicy natively matches JWT claims via the when condition with request.auth.claims keys. EnvoyFilter is tempting for low-level customisation, and would be correct for altering listener or cluster behaviour unsupported by Istio resources.

The client is disconnected.

Why it fails: Only the request is rejected, not the whole connection.

The timeout is extended.

Why it fails: Timeouts are independent of request limits.

Requests are queued until capacity is available.

Why it fails: Envoy circuit breakers do not queue; they reject.

The service is automatically scaled.

Why it fails: Istio does not trigger auto-scaling.

uri-regex

Why it fails: Not a valid key.

match-regex

Why it fails: Not a valid key.

pattern field

Why it fails: Not a standard field.

istioctl proxy-config rds <pod-name>

Why it fails: RDS is for route discovery, not authorization policies.

istioctl proxy-config listener <pod-name>

Why it fails: Listeners are for inbound/outbound ports, not policy logic.

istioctl proxy-config policy <pod-name>

Why it fails: This command does not exist.

It sets the frequency of health checks.

Why it fails: That is handled by the 'interval' field.

It defines the threshold for the circuit breaker to trip.

Why it fails: Circuit breakers have different fields for state changes.

It sets the minimum load for a host to be considered healthy.

Why it fails: This is related to load balancing weights.

It ensures at least this percentage of pods remain healthy.

Why it fails: It is a safeguard for the ejection process, not a health monitor per se.

consecutive5xx

Why it fails: This is a trigger, but often defined at the top level of outlierDetection, though it is technically an outlier detection field, 'consecutive5xx' is valid.

retryOn

Why it fails: Part of retry policy.

maxConnections

Why it fails: Part of connectionPool.

weight

Why it fails: The weight field distributes traffic across destination subsets for canary or blue-green routing; it cannot introduce failures. It is tempting because traffic splitting is used in resilience experiments, but weight only shifts load between healthy versions. Fault injection requires the fault field with abort or delay settings.

retry

Why it fails: The retry field configures automatic re-execution of failed requests; it does not inject faults. It is tempting because retries relate to resilience testing, but retry policies mask failures rather than create them. Fault injection requires the fault field, which supports abort and delay behaviours to simulate failures.

mirror

Why it fails: The mirror field copies live traffic to a shadow destination for out-of-band testing; the mirrored request's response is discarded and the primary path is unaffected. It is tempting because mirroring supports safe production testing, but it does not inject faults. Fault injection requires the fault field with abort or delay.