ICA Resilience And Fault Injection — 20 Questions

Question 1

Which TWO fields are required when configuring an 'abort' fault injection in a VirtualService?

Accepted Answer

httpStatus. Option A (httpStatus) is correct because an abort fault in an Istio VirtualService must specify the HTTP status code to return to the client, e.g., httpStatus: 500, which defines the failure response injected into the request path. Option E (percentage) is correct because the abort fault requires a percentage block (value plus optional fixedDelay) that determines what proportion of requests receive the aborted response, e.g., percentage: {value: 100}. Options B (maxDuration) and D (delay) are incorrect because they belong to timeout and delay fault configurations, not abort faults. Option C (grpcStatus) is incorrect because abort faults use httpStatus for HTTP traffic; gRPC status codes are not a field of the abort fault specification.

Answer

maxDuration

Answer

grpcStatus

Answer

delay

Question 2

Which field in the trafficPolicy of a DestinationRule controls the maximum number of pending requests in the connection pool?

Accepted Answer

maxPendingRequests. maxRequestsPerConnection is used for HTTP/1.1 and maxPendingRequests for total pending requests.

Answer

maxRequests

Answer

pendingLimit

Answer

connectionLimit

Question 3

What is the default timeout for an HTTP request in Istio when no VirtualService is defined?

Accepted Answer

15 seconds. Istio defaults to 15 seconds for request timeouts if not explicitly configured.

Answer

5 seconds

Answer

10 seconds

Answer

30 seconds

Answer

60 seconds

Answer

0 (no timeout)

Question 4

Which TWO options are required to properly implement an abort fault injection in a VirtualService?

Accepted Answer

httpStatus. In Istio's VirtualService fault injection, an abort fault is defined under the `fault.abort` field and requires exactly two subfields: `httpStatus` and `percentage`. Option B (`httpStatus`) is correct because the abort fault must specify the HTTP status code (e.g., 503) that the sidecar will return to the client instead of forwarding the request. Option C (`percentage`) is correct because it defines the proportion of requests (0–100) that will be aborted, allowing controlled fault injection. Option A (`headers`) is not required — headers are used in match conditions or header manipulation, not in the abort fault itself. Option D (`match`) is not required — match rules are optional and only restrict which requests the fault applies to, not part of the abort definition. Option E (`fixedDelay`) is incorrect because `fixedDelay` belongs to a delay fault (`fault.delay.fixedDelay`), not an abort fault.

Answer

headers

Answer

match

Answer

fixedDelay

Question 5

You want to simulate a 5-second network latency for 10% of requests to the 'cart' service. Which VirtualService configuration is correct?

Accepted Answer

fault: { delay: { percentage: { value: 10 }, fixedDelay: 5s } }. The fault injection delay policy requires both a percentage and a fixedDelay duration.

Answer

fault: { delay: { fixedDelay: 5s } }

Answer

fault: { delay: 5s, weight: 0.1 }

Answer

fault: { delay: { percentage: 10, latency: 5s } }

Answer

fault: { abort: { percentage: 10, duration: 5s } }

Question 6

You are testing resilience. You want to inject an HTTP 503 error for 20% of traffic to the 'catalog' service. Which fault setting is correct?

Accepted Answer

abort: { status: 503, percentage: { value: 20 } }. The fault injection abort policy requires an HTTP status code and a percentage.

Answer

abort: { code: 503, percent: 20 }

Answer

fault: { abort: 503, rate: 0.2 }

Answer

abort: { status: 503, ratio: 0.2 }

Answer

error: { status: 503, percentage: 20 }

Question 7

What is the purpose of 'minHealthPercent' in the OutlierDetection configuration?

Accepted Answer

It limits the number of hosts that can be ejected to keep the cluster healthy.. It prevents the ejection of hosts if it would cause the total cluster health to fall below a specific percentage.

Answer

It sets the frequency of health checks.

Answer

It defines the threshold for the circuit breaker to trip.

Answer

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

Answer

It ensures at least this percentage of pods remain healthy.

Question 8

When using 'maxRequests' in connectionPool, what happens when the threshold is reached?

Accepted Answer

Additional requests are rejected with a 503.. In Envoy, maxRequests is a circuit-breaking limit that rejects new requests with a 503 error when the limit is exceeded.

Answer

The client is disconnected.

Answer

The timeout is extended.

Answer

Requests are queued until capacity is available.

Answer

The service is automatically scaled.

Question 9

You want to configure a circuit breaker that only allows 100 concurrent requests to a service. Which field is correct?

Accepted Answer

trafficPolicy.connectionPool.http.maxRequests. trafficPolicy.connectionPool.http.http1MaxPendingRequests or maxRequests (in versions) is used to control concurrency.

Answer

trafficPolicy.outlierDetection.maxRequests

Answer

trafficPolicy.connectionPool.http.http2MaxRequests

Answer

trafficPolicy.circuitBreaker.maxRequests

Answer

trafficPolicy.connectionPool.tcp.maxConnections

Question 10

Which setting is used to limit the number of retries for a request?

Accepted Answer

attempts. In IBM App Connect (formerly IBM Integration Bus), the HTTP Request node and similar nodes use the 'attempts' property to specify the maximum number of times a request is attempted, including the initial attempt. This setting directly controls retry behavior by defining the total number of tries before the flow throws an exception. Therefore, 'attempts' is the correct property name for limiting retries.

Answer

retryLimit

Answer

maxRetries

Answer

retryCount

Answer

maxAttempts

Question 11

You want to configure outlier detection to eject hosts that return 5xx errors. Is it possible to monitor more than just 5xx codes?

Accepted Answer

Yes, using the 'consecutiveGatewayFailure' field.. Istio's outlier detection supports `consecutiveGatewayFailure`, which ejects hosts returning gateway errors (502, 503, 504) in addition to the default `consecutive5xxErrors` for 5xx responses. This lets you tune ejection based on gateway-level failures separately from application 5xx errors.

Answer

Yes, but only via an EnvoyFilter.

Answer

No, you must use circuit breaking for other codes.

Answer

Yes, using the 'regex' field.

Answer

No, only 5xx is supported.

Question 12

In a VirtualService, where is the fault injection policy defined?

Accepted Answer

Within the 'http' route block.. The fault field is defined inside the route action block of a VirtualService.

Answer

Within the 'hosts' field.

Answer

Within the 'subset' definition.

Answer

Within the 'outlierDetection' block.

Answer

Within the 'trafficPolicy' block.

Question 13

Which field in a VirtualService can you use to retry a request?

Accepted Answer

retries. The 'retries' field in the HTTP route block allows defining retry attempts and timeout per try.

Answer

attemptCount

Answer

retryPolicy

Answer

faultRetry

Answer

repeat

Question 14

Which of the following is true regarding Outlier Detection in Istio?

Accepted Answer

It automatically ejects instances that return 5xx errors.. Outlier Detection requires a destination rule and works by ejecting unhealthy instances based on their error rates.

Answer

It only works with TCP services.

Answer

It can be configured in a VirtualService.

Answer

It is used to rate limit traffic.

Answer

It requires an external monitoring tool.

Question 15

Which TWO conditions can trigger Outlier Detection ejection?

Accepted Answer

consecutive5xx. In Istio's Outlier Detection (Envoy's outlier detection), ejection is triggered by the consecutive5xx and consecutiveGatewayFailure detectors, which count consecutive 5xx responses and consecutive gateway failures (502/503/504) respectively before ejecting a host. Option A (consecutive5xx) is correct because it is a standard outlier-detection field that ejects an endpoint after a configured number of consecutive 5xx errors. Option D (consecutiveGatewayFailure) is correct because it is another standard field that ejects an endpoint after consecutive gateway errors (502, 503, 504). The other options are not outlier-detection ejection triggers: maxConnections and maxRequests are circuit-breaking (connection pool) limits, timeout is a request timeout setting, and latencyThreshold is not a valid outlier-detection field (latency-based ejection uses consecutiveLocalOriginFailures or similar, not latencyThreshold).

Answer

maxConnections

Answer

timeout

Answer

latencyThreshold

Answer

maxRequests

Question 16

Which THREE components are involved in configuring a robust resilience strategy?

Accepted Answer

DestinationRule. In Istio, a robust resilience strategy is built from three cooperating pieces: DestinationRule (B) defines the traffic policy applied to a service after routing, including load-balancing, connection pool limits, and outlier detection (circuit breaking) that ejects unhealthy endpoints. VirtualService (C) controls how requests are routed to a destination and is where resilience behaviors such as timeouts, retries, and fault injection are declared for specific routes. Retries (D) is the actual resilience mechanism configured in the VirtualService's HTTP route (e.g., attempts, perTryTimeout, retryOn) so that transient failures are automatically re-attempted before failing the request. ServiceEntry (A) is not part of a resilience strategy; it registers external services into the mesh's service registry so they can be addressed, which is about reachability rather than fault tolerance. IngressGateway (E) is an edge traffic entry point that handles inbound routing/TLS termination, not the in-mesh resilience policies themselves.

Answer

ServiceEntry

Answer

IngressGateway

Question 17

Which THREE of the following are valid sub-fields of 'outlierDetection'?

Accepted Answer

maxEjectionPercent. The outlierDetection field in Istio's DestinationRule supports several sub-fields for circuit breaking and ejection behavior. Option A, maxEjectionPercent, is correct because it defines the maximum percentage of hosts in a load balancing pool that can be ejected due to outlier detection. Option E, baseEjectionTime, is correct as it specifies the minimum ejection duration for a host, which is multiplied by the number of times the host has been ejected. Option null (interval) is correct because it sets the time interval between ejection sweep analyses, controlling how frequently outlier detection runs. Option B, consecutive5xx, is not a valid sub-field; the correct field is consecutive5xxErrors, which counts consecutive 5xx responses before ejection. Option C, retryOn, belongs to retry policies, not outlierDetection. Option D, maxConnections, is a connection pool setting, not part of outlierDetection.

Answer

consecutive5xx

Answer

retryOn

Answer

maxConnections

Question 18

Which TWO of the following are valid HTTP fault injection delay settings?

Accepted Answer

fixedDelay. In Istio's HTTP fault injection, a delay fault is configured with a fixed delay value and a percentage of requests to which the delay applies. Option B, fixedDelay, is correct because it is the exact field (e.g., fixedDelay: 5s) that specifies the duration of the injected delay for matching requests. Option D, percentage, is correct because it defines the proportion of requests (a value between 0 and 100) that receive the delay, allowing partial fault injection rather than affecting all traffic. Option A, maxDelay, is not a valid Istio HTTP delay setting; it belongs to other contexts such as retry or timeout backoff configurations. Option C, randomDelay, is not a supported field, since Istio only supports a fixed delay value, not randomized delays. Option E, minDelay, is likewise not a valid HTTP fault injection delay setting in Istio's VirtualService API.

Answer

maxDelay

Answer

randomDelay

Answer

minDelay

Question 19

Which THREE of the following are valid fields in a 'retry' policy?

Accepted Answer

perTryTimeout. In Istio's VirtualService retry policy, the valid fields are attempts, perTryTimeout, and retryOn. Option C (attempts) is correct because it specifies the number of retry attempts for a given request, which is the core of any retry policy. Option A (perTryTimeout) is correct because it sets the timeout per attempt, including the first one, and is a documented field of the retry policy. Option B (retryOn) is correct because it defines the conditions under which a retry should be attempted, such as 5xx or gateway-error. The unmarked options do not belong: backoff and maxDuration are not fields in Istio's retry policy (backoff is not supported, and maxDuration is not a retry field), and maxRetries is not a valid field name—the correct field is attempts.

Answer

backoff

Answer

maxDuration

Answer

maxRetries

Question 20

Which TWO of the following are true about Istio Circuit Breakers?

Accepted Answer

They operate at the proxy level.. Circuit breaking is implemented in the proxy and applies to individual load balancer pools.

Answer

They require a central controller check.

Answer

They are configured via ServiceEntry.

Answer

They only trigger on 5xx errors.