ICA Securing Workloads — 10 Questions

Question 1

Which TWO of the following are valid modes for PeerAuthentication?

Accepted Answer

STRICT. The two primary modes for PeerAuthentication are PERMISSIVE and STRICT.

Answer

ENABLED

Answer

OPTIONAL

Answer

DISABLED

Question 2

Which THREE actions are required to successfully secure a workload using OIDC and JWT authentication in Istio?

Accepted Answer

Define a RequestAuthentication resource specifying the issuer and jwksUri.. Option B is correct because Istio's RequestAuthentication resource is the mechanism that configures JWT validation, requiring the issuer and jwksUri so the sidecar can fetch the JSON Web Key Set and verify the token's signature and issuer. Option D is correct because Istio's JWT authentication expects the token to be presented in the standard 'Authorization: Bearer <token>' HTTP header, which the Envoy proxy extracts and validates against the RequestAuthentication configuration. Option E is correct because after RequestAuthentication validates the token, an AuthorizationPolicy is needed to enforce access control based on specific claims such as 'iss' or 'sub', allowing or denying requests according to those values. Option A is not required for OIDC/JWT authentication; PeerAuthentication with mode STRICT enforces mutual TLS between workloads, which is a separate transport-security concern and does not validate JWTs. Option C is not required because Istio's RequestAuthentication and Envoy's built-in JWT filter handle token parsing natively, so a custom EnvoyFilter to parse the JWT is unnecessary.

Answer

Apply a PeerAuthentication resource with mode STRICT.

Answer

Create an EnvoyFilter to parse the JWT.

Question 3

You want to allow traffic only from a specific namespace 'prod' to the 'backend' service. How should you define the 'AuthorizationPolicy'?

Accepted Answer

Set source.namespaces: ['prod'] in the rule.. AuthorizationPolicy uses the 'source' field to restrict traffic by namespace using the 'namespaces' attribute.

Answer

Set source.principals: ['prod'] in the rule.

Answer

Set source.ipBlocks: ['prod'] in the rule.

Answer

Set source.remoteIp: ['prod'] in the rule.

Question 4

You are debugging a '403 Forbidden' error on a service protected by an AuthorizationPolicy. Which tool is most effective for inspecting the policy enforcement in the data plane?

Accepted Answer

istioctl proxy-config log <pod-name> --level debug. The 'istioctl proxy-config' command allows you to view the actual policy configuration loaded into the Envoy proxy.

Answer

istioctl proxy-config rds <pod-name>

Answer

istioctl proxy-config listener <pod-name>

Answer

istioctl proxy-config policy <pod-name>

Question 5

Which protocol is used for the Istio data plane mTLS communication?

Accepted Answer

TLS 1.2/1.3. Istio uses mutual TLS (mTLS) over HTTP/2 or standard HTTP to provide encryption and identity.

Answer

VPN

Answer

SSH

Answer

IPsec

Question 6

Which THREE elements are part of a 'RequestAuthentication' resource?

Accepted Answer

issuer. In Istio's RequestAuthentication CRD, the issuer field (B) is correct because each JWT rule must identify the token issuer whose tokens are accepted, matched against the token's iss claim. jwtRules (D) is correct because it is the core list defining how JWTs are validated, including the issuer, JWKS location (jwksUri or jwks), audiences, and forwardOriginalToken behavior. selector (E) is correct because it determines which workloads the RequestAuthentication policy applies to via label selectors, scoping the JWT validation to specific pods. The remaining options do not belong: accessPolicy (A) is not a field of RequestAuthentication (authorization behavior is configured separately in AuthorizationPolicy), and mTLSMode (C) is not part of this resource since mutual TLS settings belong to PeerAuthentication.

Answer

accessPolicy

Answer

mTLSMode

Question 7

Which of the following is true about the 'principals' vs 'source.principals' fields?

Accepted Answer

They refer to the same concept.. They are synonymous in the context of AuthorizationPolicy; 'principals' is a shorthand within the 'source' object for identifying the workload's SPIFFE ID.

Answer

Only 'principals' is valid.

Answer

Only 'source.principals' is valid.

Answer

They refer to different concepts.

Question 8

How can you debug a failing AuthorizationPolicy rule?

Accepted Answer

Run 'istioctl analyze'.. istioctl analyze performs static analysis of Istio configuration (AuthorizationPolicies, VirtualServices, Gateways, etc.) against the cluster's actual state and reports misconfigurations, conflicts, and schema errors. It is the first-line tool for diagnosing why an AuthorizationPolicy is not taking effect, catching issues like missing selectors, wrong namespaces, or conflicting rules before runtime debugging.

Answer

Check Kubernetes logs for the API server.

Answer

Restart the sidecar.

Answer

Update the service account.

Question 9

Which THREE conditions must be met for a PeerAuthentication policy to enforce STRICT mTLS?

Accepted Answer

Sidecar sidecar-injection enabled. Option A is correct because STRICT mTLS enforcement requires that workloads actually have an Envoy sidecar proxy injected (via sidecar-injection enabled, e.g., istio-injection=enabled on the namespace or manual injection); without a sidecar, the pod cannot participate in Istio's mTLS and the policy cannot be enforced. Option D is correct because the PeerAuthentication resource must explicitly set mtls.mode: STRICT (or inherit STRICT from a mesh/namespace-level policy), since the default mode is PERMISSIVE, which allows plaintext and would not enforce strict mutual TLS. Option E is correct because STRICT mTLS depends on Istio's workload certificate provisioning (SDS-delivered certs from istiod/CA, e.g., Citadel) being healthy; if certificates cannot be issued or rotated, the sidecars cannot complete the mTLS handshake and traffic fails rather than being enforced. Option B is not required because PeerAuthentication can be applied to any namespace, not just 'default', and scope is determined by the policy's namespace or selector. Option C is not required because STRICT mTLS operates at the sidecar/proxy layer regardless of how the Service is exposed (ClusterIP, NodePort, LoadBalancer, or Ingress), so the Service type is irrelevant to mTLS enforcement.

Answer

Namespace must be 'default'

Answer

Service must be exposed via NodePort

Question 10

A service 'orders' requires a specific AuthorizationPolicy that allows GET requests only from the 'frontend' service while denying all other methods. Which configuration is correct?

Accepted Answer

Set 'action: ALLOW', 'rules: [{from: [{source: {principals: [cluster.local/ns/default/sa/frontend]}}], to: [{operation: {methods: [GET]}}]}]'.. The AuthorizationPolicy should specify the 'GET' method in the 'rules' section and match the 'frontend' principal in the 'from' source block.

Answer

Create an EnvoyFilter to intercept and drop requests.

Answer

Use a PeerAuthentication policy to filter based on HTTP methods.

Answer

Set 'action: DENY', 'rules: [{to: [{operation: {methods: [POST, PUT, DELETE]}}]}]'.