Resilience And Fault Injection practice questions

httpStatus

An abort fault must return an HTTP error code to the caller, and httpStatus supplies that code, which the Envoy filter uses to short-circuit the request. Without it the abort action has no response status to send, so the fault cannot be injected.

percentage

The percentage field defines what proportion of matching requests receive the abort, expressed as a value. It satisfies the requirement to scope the fault rather than failing every request, letting you inject errors into only a fraction of traffic.

maxPendingRequests

`maxPendingRequests` directly sets the connection pool's queue limit for requests awaiting an available upstream connection, satisfying the stem's requirement for the maximum pending requests field. It sits alongside `http1MaxPendingRequests` and `http2MaxRequests` under `connectionPool`, which governs overflow behaviour when all connections are busy.

15 seconds

Without a VirtualService route rule, Istio's Envoy sidecar applies its built-in default route timeout of 15 seconds to HTTP requests. This is the fallback value when no explicit timeout is configured, so 15 seconds matches the platform default.

httpStatus

An abort fault injection returns a fixed HTTP status code to the caller instead of forwarding the request. The httpStatus field supplies that code, so Istio knows which response to synthesise; without it the abort action has no defined return value.

percentage

Required to define the request frequency.

fault: { delay: { percentage: { value: 10 }, fixedDelay: 5s } }

The delay fault injection block satisfies both constraints: `fixedDelay: 5s` imposes the required five-second latency, while `percentage: { value: 10 }` restricts injection to one tenth of requests. Istio applies this at the Envoy proxy, delaying responses for the 'cart' VirtualService without affecting the remaining 90% of traffic.

abort: { status: 503, percentage: { value: 20 } }

The abort fault with status 503 and percentage value 20 makes Envoy reject exactly 20% of requests to catalog with HTTP 503, matching the required error rate. Percentage is expressed as a value field, not a bare number.

It limits the number of hosts that can be ejected to keep the cluster healthy.

The minHealthPercent setting defines the minimum percentage of healthy hosts that must remain in the load-balancing pool. Once ejection of unhealthy hosts would drop the healthy proportion below this threshold, outlier detection stops evicting, preventing cascading failures and preserving cluster capacity during widespread degradation.

Additional requests are rejected with a 503.

Once `maxRequests` is reached, the connection pool refuses further connection attempts, and the integration runtime surfaces the failure as an HTTP 503 response. This satisfies the stem's threshold constraint by bounding concurrent outbound connections, protecting downstream systems from overload rather than queueing or silently dropping requests.

trafficPolicy.connectionPool.http.maxRequests

Setting `trafficPolicy.connectionPool.http.maxRequests` to 100 caps concurrent HTTP requests at the connection pool, which is exactly the concurrency limit the stem requires. Istio's circuit breaker enforces this per destination host, so excess requests queue or fail fast rather than overwhelming the service.

attempts

In Istio's VirtualService retry policy, the attempts field specifies how many times Envoy retries a failed request before returning the error to the caller. It directly caps retry volume, unlike perTryTimeout, which bounds each individual attempt's duration.

Yes, using the 'consecutiveGatewayFailure' field.

This allows targeting specific types of errors commonly associated with network/mesh issues.

Within the 'http' route block.

Fault injection belongs in the HTTP route block because Istio applies abort and delay rules per matched route, not at the VirtualService root. The route-level placement satisfies the requirement that faults target specific traffic, since each route carries its own match conditions, timeout and retry settings.

retries

The `retries` field in a VirtualService specifies retry policy for failed requests, including attempts, per-try timeout, and retry conditions. It directly satisfies the stem's requirement to retry a request, unlike fields governing routing, fault injection, or traffic splitting. Istio applies this policy when upstream responses match the configured conditions.

It automatically ejects instances that return 5xx errors.

Outlier detection ejects hosts from the load-balancing pool based on consecutive 5xx responses (or gateway errors), applying the configured consecutive5xxErrors threshold. This matches the stem's constraint by naming the actual ejection trigger: upstream 5xx failures, not latency or connection state.

consecutive5xx

consecutive5xx counts consecutive responses with 5xx status codes from an endpoint. When the count exceeds the configured threshold within the interval, Envoy ejects that host, making it one of the triggers for outlier detection ejection.

consecutiveGatewayFailure

Gateway-specific error trigger.

DestinationRule

DestinationRule defines traffic policies for a service after routing, including load-balancing algorithm, connection pool limits and outlier detection that ejects unhealthy endpoints. It supplies the failover and health-checking behaviour a resilience strategy needs alongside VirtualService routing rules.

VirtualService

VirtualService is an Istio traffic-routing resource that controls how requests reach services, enabling failover, traffic shifting and fault injection. Including it satisfies the stem's requirement for components involved in configuring a robust resilience strategy across the service mesh.

Retries

Retries configure automatic reattempts of failed requests, a core resilience mechanism that absorbs transient faults without surfacing errors to users. Including retries satisfies the stem's requirement for components involved in configuring a robust resilience strategy within the service mesh.

maxEjectionPercent

maxEjectionPercent is a valid outlierDetection sub-field, capping the proportion of hosts Istio may eject from a load-balancing pool. It satisfies the stem's requirement by belonging to the outlierDetection schema, unlike unrelated traffic-management fields. Istio uses it alongside consecutive5xxErrors and interval to bound ejection, preventing a single policy from removing every endpoint.

baseEjectionTime

baseEjectionTime is a valid sub-field of outlierDetection, specifying how long an ejected host remains excluded from the load-balancing pool before being returned. It directly satisfies the stem's requirement by naming an actual configuration parameter within the outlierDetection block, alongside consecutiveErrors and interval.

interval

The `interval` sub-field sets the minimum number of consecutive data points required before Microsoft Entra ID reports an outlier, directly satisfying the stem's requirement for a valid `outlierDetection` sub-field. It controls detection sensitivity by defining the sliding window size, so shorter intervals flag anomalies faster but risk more false positives.

fixedDelay

`fixedDelay` injects a constant latency value into every affected request, satisfying the requirement for a deterministic, unchanging delay. Unlike probabilistic or distribution-based settings, it applies one uniform duration, so responses are delayed by exactly the configured amount on each call.

percentage

Percentage sets what proportion of matching requests receive the injected delay, letting you apply latency to only a subset rather than every call. This satisfies the stem's requirement for a valid HTTP fault injection delay setting, since Chaos Studio pairs it with the delay duration to control blast radius.

perTryTimeout

perTryTimeout sets the timeout for each individual retry attempt, distinct from the overall request timeout. It is a valid retry-policy field in Istio's VirtualService HTTPRetry, letting operators bound how long any single attempt may run before the next retry fires.

retryOn

retryOn specifies the conditions triggering a retry, such as 5xx, gateway-error, reset or connect-failure. It is a valid field in Istio's HTTPRetry policy, controlling which response codes or failures cause the proxy to reattempt the request.

attempts

`attempts` is a valid retry policy field, specifying the maximum number of times a failed request is re-sent before the policy gives up. It satisfies the stem's requirement for a genuine retry configuration field, unlike unrelated settings such as timeout or authentication parameters.

They operate at the proxy level.

The sidecar enforces it.

They can be applied to specific subsets.

DestinationRules allow subsets with different policies.