ICA Securing Workloads Practice Test 2 — 15 Questions

Question 1

You have deployed Istio with mutual TLS enabled globally. A new service 'inventory' is added to the mesh, but its sidecar is not injected due to a misconfiguration. What will happen to traffic between 'inventory' and other services that have sidecars?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Traffic will be rejected because the source does not have a sidecar to originate mTLS, and the destination requires mTLS.. With global mTLS enabled in STRICT mode, destination sidecars require mTLS. A source without a sidecar cannot originate mTLS, so its plaintext traffic will be rejected by the destination sidecar. This enforces the security policy but can cause connectivity issues if sidecar injection is missed. The correct answer reflects this rejection.

Answer

Traffic will be automatically upgraded to mTLS by the destination sidecar, even if the source lacks a sidecar.

Answer

Traffic will be allowed if the destination has PERMISSIVE mode enabled, otherwise it will be rejected.

Answer

Traffic will be sent in plaintext, and the destination sidecar will reject it because it expects mTLS.

Question 2

Your security team requires that all inbound requests to the 'orders' service carry a valid JWT from issuer 'https://auth.example.com' with audience 'orders-api'. You apply a RequestAuthentication policy with the appropriate issuer and jwksUri, and an AuthorizationPolicy that requires request.auth.claims[aud] to equal 'orders-api'. However, you notice that requests without any JWT are still being allowed. What is the most likely cause?

Accepted Answer

The AuthorizationPolicy does not include a rule that denies requests when request.auth is absent, so unauthenticated requests bypass the JWT claim check.. RequestAuthentication validates JWTs but does not reject requests without one. To enforce authentication, an AuthorizationPolicy must explicitly require a valid JWT, for example by checking request.auth.claims or request.auth.present. If the policy only checks a claim like aud, requests without a token will lack that claim and thus not match the rule; but if the policy has no rule that denies such requests and the default is allow, they slip through. The fix is to add a rule that requires authentication.

Answer

The RequestAuthentication policy is applied to the wrong namespace, so it is not enforced for the 'orders' service.

Answer

The RequestAuthentication policy is missing the 'audiences' field, so audience validation is skipped.

Answer

The AuthorizationPolicy is missing the 'action: DENY' field, so it defaults to allow.

Question 3

You are troubleshooting why an AuthorizationPolicy is not blocking traffic as expected in the 'secure' namespace. Which TWO of the following are common reasons for an AuthorizationPolicy to be ineffective? (Choose two.)

Accepted Answer

The sidecar proxy is not injected into the target workload, so the policy cannot be enforced.. An AuthorizationPolicy can be ineffective if it is applied to the wrong namespace or lacks a matching selector, or if the target workload does not have a sidecar proxy to enforce it. These are two fundamental requirements for policy enforcement. Without a matching workload and a sidecar, the policy is not applied. Other issues like DENY vs ALLOW precedence or missing fields are less common or not applicable in typical scenarios.

Answer

The AuthorizationPolicy uses a DENY action, but an ALLOW policy with a broader match is also present.

Answer

The AuthorizationPolicy is configured with an action of CUSTOM, but no custom authorization provider is registered.

Answer

The AuthorizationPolicy is missing a 'requestPrincipals' field, so it cannot match any requests.

Question 4

You are reviewing the security posture of a service mesh. You need to verify that mutual TLS is enforced for all workloads in the 'default' namespace. Which TWO of the following are valid ways to enforce or verify mTLS enforcement in Istio? (Choose two.)

Accepted Answer

Use 'istioctl authn tls-check' to verify that the mTLS status between two workloads is OK.. Enforcing mTLS in Istio is done by applying a PeerAuthentication policy with mode STRICT, which makes workloads reject plaintext traffic. Verification can be performed using 'istioctl authn tls-check' to confirm the effective mTLS status between workloads. Other options either disable mTLS or are insufficient for enforcement. Together, applying STRICT mode and verifying with istioctl provide a robust approach.

Answer

Create a DestinationRule with trafficPolicy.tls.mode: DISABLE for all services in the namespace.

Answer

Set the 'meshConfig.enableAutoMtls' flag to false in the IstioOperator configuration.

Answer

Check the 'istio_requests_total' metric for the 'connection_security_policy' label set to 'mutual_tls'.

Question 5

A security team requires that all traffic to the 'payments' service must originate from a specific IP range (10.0.0.0/24). How can this be achieved?

Accepted Answer

Create an AuthorizationPolicy with 'source.ipBlocks: ["10.0.0.0/24"]'.. The AuthorizationPolicy supports 'source.ipBlocks' to whitelist or blacklist specific CIDR ranges.

Answer

Configure the Gateway to filter by IP.

Answer

Use a ServiceEntry to restrict traffic.

Answer

Create a PeerAuthentication policy with 'ipBlocks'.

Question 6

What is the default behavior of Istio when no AuthorizationPolicy is present for a workload?

Accepted Answer

Allow all traffic.. By default, Istio allows all traffic (PERMISSIVE/ALLOW ALL) unless an explicit policy is defined.

Answer

Allow only traffic within the same namespace.

Answer

Deny all traffic.

Answer

Require mTLS for all traffic.

Question 7

You have a requirement to use a custom JWT claim to authorize users. How can you map this claim in an 'AuthorizationPolicy'?

Accepted Answer

Use the 'when' field with 'key: request.auth.claims[custom-claim]' and 'values' to match.. AuthorizationPolicy supports 'when' conditions to evaluate JWT claims using the 'request.auth.claims' key.

Answer

Use the 'principals' field.

Answer

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

Answer

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

Question 8

Which Istio component is responsible for enforcing the AuthorizationPolicy at the workload level?

Accepted Answer

Envoy Proxy. The Envoy proxy (sidecar) intercepts all inbound and outbound traffic and enforces policies defined in AuthorizationPolicy.

Answer

Citadel

Answer

Ingress Gateway

Answer

Istiod

Question 9

You have a namespace 'finance' where all traffic must be encrypted using mutual TLS. You apply a PeerAuthentication policy with 'mode: STRICT' at the namespace scope. A developer reports that a legacy service in the same namespace is failing to communicate. What is the most likely reason?

Accepted Answer

The legacy service is not using an Istio sidecar to handle mTLS handshakes.. A PeerAuthentication policy with mode: STRICT at the namespace scope requires all inbound traffic to workloads in that namespace to use Istio mutual TLS. Only workloads with an Istio sidecar proxy can originate and terminate mTLS, so a legacy service without a sidecar cannot complete the mTLS handshake and its connections fail. The fix is either to inject a sidecar into the legacy service or to use a permissive mode or port-level exception during migration.

Answer

The Gateway is misconfigured for the legacy service.

Answer

The DestinationRule for the service is missing the 'mode: ISTIO_MUTUAL' setting.

Answer

The AuthorizationPolicy is missing a rule for the legacy service.

Question 10

Which THREE items are included in an Istio SPIFFE ID?

Accepted Answer

Trust domain. An Istio SPIFFE ID follows the format spiffe:///ns//sa/, so the three components it includes are the trust domain (A), the namespace (D), and the service account (C). The trust domain (A) is the first segment after the spiffe:// scheme and identifies the identity's issuing authority, which in Istio defaults to cluster.local. The namespace (D) appears in the /ns/ path segment and scopes the workload identity to its Kubernetes namespace. The service account (C) appears in the /sa/ path segment and represents the Kubernetes service account under which the workload runs. Cluster Name (B) is not part of the SPIFFE ID format—it is a separate Istio concept used in multi-cluster configurations and mesh expansion. IP Address (E) is not encoded in a SPIFFE ID; Istio identities are based on service account and namespace, not network addresses.

Answer

Cluster Name

Answer

IP Address

Question 11

Which THREE fields in an AuthorizationPolicy are evaluated under the 'rules' section?

Accepted Answer

from. In an Istio AuthorizationPolicy, the 'rules' section defines the conditions under which the policy applies, and each rule can contain the fields 'from', 'to', and 'when'. Option C ('from') is correct because it specifies the source of the request, such as a source principal, namespace, or IP block, and is evaluated as part of the rule matching. Option E ('to') is correct because it defines the destination attributes of the request, including operation methods, paths, and ports, which are matched within the rule. Option D ('when') is correct because it provides additional custom conditions using Istio attributes (e.g., request.headers, source.ip) that must be satisfied for the rule to match. Option A ('action') is not part of the 'rules' section; it is a top-level field of the AuthorizationPolicy that specifies ALLOW, DENY, AUDIT, or CUSTOM. Option B ('selector') is also not part of the 'rules' section; it is a top-level field used to target specific workloads by label.

Answer

action

Answer

selector

Question 12

If you apply an AuthorizationPolicy with a 'DENY' action and an 'ALLOW' action in the same namespace, how does Istio resolve them?

Accepted Answer

DENY policies always take precedence over ALLOW policies.. Istio's AuthorizationPolicy evaluation follows a deny-overrides model: if any DENY policy matches a request, the request is rejected regardless of any matching ALLOW policies. ALLOW policies are only evaluated if no DENY policy matches, and if at least one ALLOW policy exists in the namespace, a request must match one to be permitted. This ordering is enforced by the Envoy RBAC filter that Istio programs into the sidecar.

Answer

ALLOW policies take precedence.

Answer

The policy with the highest priority field wins.

Answer

The policy applied most recently wins.

Question 13

What is the primary function of the 'root-cert.pem' file in the Istio control plane?

Accepted Answer

To establish the chain of trust for mTLS.. root-cert.pem is the root CA certificate used by Istio's Citadel (istiod) to sign intermediate CA certificates, which in turn sign workload certificates. It anchors the chain of trust that enables mutual TLS between sidecars, so every workload certificate can be verified back to this root. Without a shared root, mTLS handshakes between meshes or across clusters fail.

Answer

To authorize HTTP requests.

Answer

To authenticate JWT tokens.

Answer

To encrypt user data in transit.

Question 14

What does the 'jwksUri' field in a RequestAuthentication resource define?

Accepted Answer

The URL to fetch the public keys for JWT validation.. The jwksUri specifies the endpoint where the JWT issuer publishes its public keys, used by Istio to verify the token signature.

Answer

The URL to register the application.

Answer

The location where JWTs are stored.

Answer

The address of the Identity Provider login page.

Question 15

Which of the following is true regarding PeerAuthentication and sidecar-less ambient mode?

Accepted Answer

It is enforced by the ztunnel on the node.. PeerAuthentication applies to the ztunnel in ambient mode to enforce mTLS for traffic between nodes.

Answer

It requires manual certificate rotation.

Answer

It only works with sidecar proxies.

Answer

PeerAuthentication is not supported in ambient mode.