ICA Resilience And Fault Injection Practice Test 2 — 15 Questions

Question 1

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 2

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 3

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 4

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 5

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.

Question 6

Which THREE items can you configure in a VirtualService to improve resilience?

Accepted Answer

Retries. In an Istio VirtualService, resilience is improved by configuring retries (A), which automatically re-attempt failed requests according to conditions like attempts, perTryTimeout, and retryOn, reducing the impact of transient failures. Timeouts (C) are also set in the VirtualService via the timeout field, bounding how long a request may take and preventing a slow upstream from exhausting client resources. Fault Injection (E) is configured in the VirtualService through httpFaultInjection (delay/abort) to test and harden resilience by simulating failures and latency, validating that retry and timeout policies behave correctly. Connection Pool (B) and Outlier Detection (D) are not VirtualService fields; they belong to the DestinationRule resource (connectionPool and outlierDetection), so they cannot be configured in a VirtualService.

Answer

Connection Pool

Answer

Outlier Detection

Question 7

Which TWO of the following are valid connectionPool fields?

Accepted Answer

tcp. In MongoDB's connection string / URI options, the connectionPool-related fields are named after the transport protocols MongoDB supports, and the two valid values here are tcp (option C) and http (option D is not correct; option E is http, which is marked correct). Option C, tcp, is correct because MongoDB's connection pool settings can be scoped to the TCP transport, e.g. maxPoolSize applies to TCP connections used by drivers and mongod/mongos. Option E, http, is correct because MongoDB exposes an HTTP interface/transport (the legacy HTTP status interface on port 28017 and the HTTP-based monitoring/health-check endpoints), and connection pool configuration can be specified for the http transport in contexts such as the MongoDB Connector for BI or Atlas monitoring. Options A (udp), B (smtp), and D (ftp) are not valid connectionPool fields because MongoDB does not use UDP, SMTP, or FTP as transport protocols for client connections or its connection pool configuration.

Answer

udp

Answer

smtp

Answer

ftp

Question 8

You are configuring a VirtualService for the 'payments' service. You want to inject a 3-second delay for 10% of requests that carry the header 'x-test: true'. Which fault configuration accomplishes this while leaving all other traffic unaffected?

Accepted Answer

http:
- match:
  - headers:
      x-test:
        exact: "true"
  fault:
    delay:
      percentage:
        value: 10.0
      fixedDelay: 3s. The correct configuration uses the fault.delay block with a percentage and fixedDelay, scoped by a header match. This ensures only requests with 'x-test: true' are affected, and only 10% of those experience the 3-second delay. The other options either use the wrong fault type, misplace the delay field, or are unconventional in ordering.

Answer

http:
- match:
  - headers:
      x-test:
        exact: "true"
  fault:
    abort:
      percentage:
        value: 10.0
      httpStatus: 503

Answer

http:
- match:
  - headers:
      x-test:
        exact: "true"
  delay:
    percentage:
      value: 10.0
    fixedDelay: 3s

Answer

http:
- fault:
    delay:
      percentage:
        value: 10.0
      fixedDelay: 3s
  match:
  - headers:
      x-test:
        exact: "true"

Question 9

A platform operator needs to inject a 2-second delay into 10% of requests sent to the 'reviews' service so that callers exercise their client-side timeout logic. The team has already created a VirtualService that routes all traffic to the reviews service and wants to apply the delay only to a subset of requests. Which VirtualService configuration accomplishes this?

Accepted Answer

Add a fault with delay.percent: 10 and fixedDelay: 2s directly under the http route, without any match condition.. Fault injection in Istio uses the fault field inside an HTTP route. To delay a percentage of requests, you configure a delay fault with a percentage and a fixedDelay value. Placing it directly under the http route without a match condition ensures that all traffic to the reviews service is subject to the 10% probability, which is what allows every caller to potentially experience the 2-second latency and validate its own timeout configuration.

Answer

Set the http route's timeout field to 2s and add a retry policy with attempts: 3.

Answer

Add an http match with a header condition and configure a fault with delay.percent: 10 and fixedDelay: 2s.

Answer

Add a fault with abort.httpStatus: 503 and abort.percentage: 10 under the http route.

Question 10

You are configuring a DestinationRule for the 'inventory' service to improve resilience. You want to set up outlier detection to eject unhealthy hosts. Which TWO fields are required to enable outlier detection and specify the criteria for ejection? (Choose two.)

Accepted Answer

consecutive5xxErrors. Outlier detection requires consecutive5xxErrors to define the error threshold and interval to set the evaluation frequency. These two fields are essential to enable and specify the criteria for ejecting unhealthy hosts. The other fields are optional tuning parameters that control the extent and duration of ejections but are not required to activate the feature.

Answer

maxEjectionPercent

Answer

minHealthPercent

Answer

baseEjectionTime

Question 11

A site reliability engineer is tuning a DestinationRule for the 'payments' service. The goal is to eject a pod from the load-balancing pool when it returns five consecutive 5xx errors, but only for 30 seconds, after which the pod should be reconsidered. The team also wants to ensure that at most 40% of the endpoints can be ejected at any time. Which combination of OutlierDetection settings achieves this?

Accepted Answer

consecutive5xxErrors: 5, baseEjectionTime: 30s, maxEjectionPercent: 40, interval: 10s. Outlier detection in a DestinationRule uses consecutive5xxErrors to define the failure threshold, baseEjectionTime to set how long a host is ejected, maxEjectionPercent to cap the ejected fraction, and interval to control evaluation frequency. To eject after five consecutive 5xx errors for 30 seconds while capping ejection at 40%, the correct fields are consecutive5xxErrors: 5, baseEjectionTime: 30s, maxEjectionPercent: 40, and an interval that governs how often the scan runs.

Answer

consecutive5xxErrors: 5, baseEjectionTime: 30s, maxEjectionPercent: 100, interval: 10s

Answer

consecutive5xxErrors: 5, interval: 30s, maxEjectionPercent: 40, minHealthPercent: 30

Answer

consecutive5xxErrors: 5, interval: 30s, baseEjectionTime: 30s, maxEjectionPercent: 40

Question 12

You are using Istio to manage traffic to a legacy service that occasionally returns HTTP 500 errors. You want to configure retries so that the sidecar retries failed requests up to 3 times, but only for idempotent GET requests. Which VirtualService configuration achieves this?

Accepted Answer

match:
- method:
    exact: GET
retries:
  attempts: 3
  retryOn: 5xx. To retry only GET requests, you must include a match block that selects the GET method before defining the retries. The correct configuration combines a method match with retry attempts and retryOn: 5xx. The other options either omit the method match or use incorrect retry conditions, failing to restrict retries to idempotent requests.

Answer

retries:
  attempts: 3
  retryOn: gateway-error,connect-failure

Answer

retries:
  attempts: 3
  retryOn: 5xx
  perTryTimeout: 2s

Answer

retries:
  attempts: 3
  retryOn: 5xx
  retryRemoteLocalities: true

Question 13

A developer is configuring a VirtualService for the 'inventory' service. The service occasionally returns transient 503 errors, and the team wants the sidecar to retry failed requests up to three times with a 1-second timeout per attempt, but only for requests that use the GET method. Which retry configuration in the VirtualService accomplishes this?

Accepted Answer

retries: { attempts: 3, perTryTimeout: 1s, retryOn: '5xx' } with an http match on method GET.. Retry policies in a VirtualService are defined under the retries field. To retry on 5xx responses, retryOn must include '5xx'. The attempts field sets the maximum number of retries, and perTryTimeout sets the timeout for each attempt. Scoping the retry to GET requests requires an http match on method GET. Together, these settings ensure that only GET requests to the inventory service are retried up to three times with a one-second timeout per attempt.

Answer

retries: { attempts: 3, perTryTimeout: 1s, retryOn: 'gateway-error' } with an http match on method GET.

Answer

retries: { attempts: 3, perTryTimeout: 1s, retryOn: 'reset' } with an http match on method GET.

Answer

retries: { attempts: 3, perTryTimeout: 1s, retryOn: 'connect-failure' } with an http match on method GET.

Question 14

You are configuring connection pool settings for the 'checkout' service in a DestinationRule. You want to limit the number of concurrent HTTP/2 requests to 100 and ensure that excess requests are queued up to a maximum of 50. Which configuration snippet correctly sets these limits?

Accepted Answer

trafficPolicy:
  connectionPool:
    http:
      http2MaxRequests: 100
      maxPendingRequests: 50. The correct configuration uses http2MaxRequests to limit concurrent HTTP/2 requests and maxPendingRequests to set the queue size for excess requests. Both fields belong under connectionPool.http. The other options either use incorrect fields, swap values, or apply TCP settings that do not address HTTP/2 request concurrency and queuing.

Answer

trafficPolicy:
  connectionPool:
    http:
      http1MaxPendingRequests: 100
      http2MaxRequests: 50

Answer

trafficPolicy:
  connectionPool:
    http:
      http2MaxRequests: 100
      maxRequestsPerConnection: 50

Answer

trafficPolicy:
  connectionPool:
    tcp:
      maxConnections: 100
      connectTimeout: 50ms

Question 15

Which THREE settings are part of the 'outlierDetection' configuration in a DestinationRule?

Accepted Answer

interval. In Istio's DestinationRule, the outlierDetection block configures passive health checking (circuit breaking) that ejects unhealthy hosts from the load-balancing pool. Option A, interval, is correct because it defines the time interval between ejection sweep analyses of the hosts (e.g., 10s), controlling how often the outlier detection scan runs. Option B, baseEjectionTime, is correct because it specifies the minimum ejection duration for an outlier host, and the actual ejection time is multiplied by the number of times the host has been ejected. Option E, consecutive5xxErrors, is correct because it is the threshold of consecutive 5xx errors a host must return before it is ejected from the pool. Option C, requestRetryCount, is not part of outlierDetection; retry behavior is configured under the DestinationRule's trafficPolicy retries or the VirtualService retries block. Option D, maxConnectionTimeout, is not a valid outlierDetection field; connection pool timeouts are configured under connectionPool.tcp (e.g., connectTimeout) in the DestinationRule.

Answer

requestRetryCount

Answer

maxConnectionTimeout