ICA Securing Workloads Practice Test 3 — 15 Questions

Question 1

How do you ensure that a workload ignores a global PeerAuthentication policy?

Accepted Answer

Apply a PeerAuthentication policy with a selector matching the specific workload.. A workload-specific PeerAuthentication policy (with a selector) will override a global (namespace or root) policy.

Answer

Use an AuthorizationPolicy to bypass mTLS.

Answer

Delete the global policy.

Answer

Set the 'mode' to 'DISABLE' in a DestinationRule.

Question 2

What is the primary purpose of the 'RequestAuthentication' resource?

Accepted Answer

To define JWT validation requirements.. RequestAuthentication is used to define which JWT issuers are trusted and how to validate tokens.

Answer

To issue new JWTs.

Answer

To store user credentials.

Answer

To encrypt traffic between services.

Question 3

Which of the following describes the role of the 'trust-domain' in Istio?

Accepted Answer

It defines the root of trust for identity.. The trust domain identifies the administrative boundary for identities. It is used to construct the SPIFFE ID.

Answer

It is used for load balancing.

Answer

It determines the namespace scope of policies.

Answer

It limits the number of concurrent connections.

Question 4

In an AuthorizationPolicy, what does the 'ALLOW' action mean when combined with an empty rule set?

Accepted Answer

It allows all requests.. An empty 'rules' section in an 'ALLOW' policy effectively allows all requests that meet the identity criteria, or if no source/to constraints are specified, it allows everything.

Answer

It crashes the proxy.

Answer

It requires valid mTLS.

Answer

It denies all requests.

Question 5

Which THREE actions occur when 'mode: STRICT' is set in a PeerAuthentication policy?

Accepted Answer

The client proxy initiates mTLS handshakes.. In Istio, setting mode: STRICT in a PeerAuthentication policy enforces mutual TLS for all workloads in the targeted scope, so option B is correct because the client-side Envoy proxy initiates the mTLS handshake with the server proxy, presenting its certificate. Option C is correct because the receiving sidecar proxy validates the peer's identity by verifying the presented X.509 certificate against the trusted CA (Istiod's root), which is the core of mTLS peer authentication. Option E is correct because in STRICT mode the server proxy rejects any plaintext (non-mTLS) traffic, allowing only connections that complete a valid mTLS handshake. Option A is wrong because PeerAuthentication only governs transport authentication between sidecars; it does not reroute non-Istio traffic to an ingress gateway. Option D is wrong because automatic HTTP-to-HTTPS redirection is a feature of Gateway/VirtualService or the istio-ingressgateway configuration, not of PeerAuthentication STRICT mode.

Answer

All non-Istio traffic is automatically routed to the gateway.

Answer

The proxy automatically upgrades HTTP to HTTPS.

Question 6

Which THREE components are involved in the Istio certificate management process?

Accepted Answer

Istiod. The certificate lifecycle involves Istiod (CA), the control plane agent, and the workload sidecar/proxy.

Answer

Ingress Gateway

Answer

Kubernetes Secret

Question 7

Which tool would you use to verify if a pod has an active mTLS connection?

Accepted Answer

istioctl proxy-config secret . The command `istioctl proxy-config secret ` lists the secrets (certificates) loaded in the Envoy sidecar, including the workload's mTLS certificate and the root CA. If mTLS is active, you will see the default or custom certificate with its validity and the ROOTCA. This directly confirms that the sidecar has an mTLS identity and is participating in mutual TLS.

Answer

istioctl proxy-config endpoint <pod-name>

Answer

istioctl dashboard envoy <pod-name>

Answer

kubectl get mTLS

Question 8

Which TWO scenarios indicate that a PeerAuthentication policy is working correctly?

Accepted Answer

Requests are rejected when mTLS is not used by the client.. Option A is correct because a PeerAuthentication policy set to STRICT mode enforces mutual TLS, so any request arriving without a valid mTLS client certificate is rejected by the sidecar proxy — this rejection is exactly the expected enforcement behavior. Option D is correct because in STRICT mode, workloads that have sidecar proxies (and thus can present and validate mTLS certificates) are able to communicate with each other successfully, demonstrating that the policy permits properly authenticated mesh traffic. Option B is wrong because STRICT mode should block, not allow, non-mTLS traffic from outside the mesh unless it is upgraded to mTLS. Option C is wrong because Envoy logs being in plain text says nothing about PeerAuthentication enforcement and is unrelated to mTLS policy validation. Option E is wrong because PeerAuthentication does not control the Kubernetes API server, and non-mTLS traffic is not allowed by default under a STRICT policy.

Answer

Traffic from outside the mesh can reach the service in STRICT mode without modification.

Answer

All traffic is logged in plain text in the Envoy logs.

Answer

The API server allows non-mTLS traffic by default.

Question 9

What happens if a RequestAuthentication policy is applied, but no JWT is provided in the request?

Accepted Answer

The request is allowed by default.. In Istio, a RequestAuthentication policy only validates JWTs if they are present. If no JWT is provided, the request is allowed by default unless an AuthorizationPolicy explicitly requires authentication. This is because RequestAuthentication does not enforce rejection; it only specifies how to validate tokens. To reject requests without valid tokens, you must pair it with an AuthorizationPolicy that requires a valid JWT.

Answer

The request is routed to the login page.

Answer

The request is rejected automatically.

Answer

The request is dropped.

Question 10

How can you restrict a service to only accept requests from users authenticated via a specific JWT issuer?

Accepted Answer

RequestAuthentication for issuer, then AuthorizationPolicy to verify.. You define a RequestAuthentication policy that specifies the trusted issuer, and then use an AuthorizationPolicy that checks for the 'request.auth.claims[iss]' claim.

Answer

Only DestinationRule.

Answer

Only ServiceEntry.

Answer

Only PeerAuthentication.

Question 11

What does an AuthorizationPolicy's 'operation' field represent?

Accepted Answer

HTTP methods and paths.. The operation field defines the methods (GET, POST) and paths allowed or denied.

Answer

Certificate details.

Answer

IP addresses.

Answer

User identities.

Question 12

You have a global PeerAuthentication policy. What is the effect of applying a new PeerAuthentication policy in the 'default' namespace with no selector?

Accepted Answer

It overrides the global policy for all workloads in the 'default' namespace.. In Istio, PeerAuthentication policies are scoped hierarchically: mesh-wide (root namespace, no selector), namespace-wide (a namespace, no selector), and workload-specific (with a selector). A namespace-wide policy in 'default' with no selector applies to all workloads in that namespace and takes precedence over the mesh-wide global policy for those workloads, effectively overriding it.

Answer

It is ignored.

Answer

It crashes the global policy.

Answer

It merges with the global policy.

Question 13

What is the correct syntax for a principal in an AuthorizationPolicy?

Accepted Answer

cluster.local/ns/default/sa/my-service. The principal follows the SPIFFE ID format: 'cluster.local/ns/default/sa/my-service'.

Answer

spiffe://my-service

Answer

default/my-service

Answer

my-service.default

Question 14

If you set 'mode: PERMISSIVE' in PeerAuthentication, what does this allow?

Accepted Answer

It allows both mTLS and plaintext.. PERMISSIVE mode allows both mTLS and plaintext traffic to coexist, which is ideal for migrations.

Answer

It requires plaintext only.

Answer

It requires mTLS only.

Answer

It disables all security.

Question 15

Why might a 'RequestAuthentication' policy fail to validate a JWT even if the issuer is correct?

Accepted Answer

The proxy cannot reach the JWKS URI.. A RequestAuthentication policy in Istio validates JWTs by fetching the JSON Web Key Set (JWKS) from the issuer's specified JWKS URI. If the proxy cannot reach that URI (due to network policies, DNS failures, or the endpoint being down), it cannot retrieve the public keys needed to verify the token's signature, causing validation to fail even when the issuer claim is correct. This is a common operational issue in service meshes where egress restrictions or misconfigured service entries block access to external identity providers.

Answer

The pod is missing a sidecar.

Answer

The namespace is missing.

Answer

The JWT is too long.