Question 6 of 500
Configuring access and securitymediumMultiple ChoiceObjective-mapped

Google ACE Configuring access and security Practice Question

This ACE practice question tests your understanding of configuring access and security. The scenario asks you to isolate a root cause — eliminate options that address a different problem before choosing. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.

Your company runs a microservices application on Google Kubernetes Engine (GKE) with a shared VPC. The security team requires that all pod-to-pod traffic be encrypted using TLS. Additionally, you need to restrict which pods can communicate with each other. The application uses a service mesh with Istio. You have enabled Istio mTLS in STRICT mode, but you notice that some pods are still able to communicate with other pods without TLS. You have verified that all pods have the Istio sidecar injected. What should you do to fix the issue?

Question 1mediummultiple choice
Full question →

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Apply a Kubernetes Network Policy to deny all non-mTLS traffic.

Option C is correct because Istio mTLS in STRICT mode only enforces encryption between sidecars that are properly configured and have discovered each other via the Istio control plane. However, if a pod bypasses the sidecar (e.g., by using a hostNetwork or a non-sidecar port), or if the sidecar is not enforcing the policy due to a misconfiguration, plaintext traffic can still flow. Applying a Kubernetes Network Policy that explicitly denies all non-mTLS traffic (e.g., by blocking TCP port 80 and allowing only port 443 or the Istio mTLS port) provides a defense-in-depth layer that blocks any unencrypted communication at the network layer, regardless of sidecar behavior.

Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Enable VPC Flow Logs to identify the unencrypted traffic.

    Why it's wrong here

    Flow Logs help with observation but do not enforce encryption.

  • Restart all pods to force re-injection of the sidecar.

    Why it's wrong here

    Sidecars are already injected; restarting won't fix the issue.

  • Apply a Kubernetes Network Policy to deny all non-mTLS traffic.

    Why this is correct

    Network Policies can restrict traffic to only that going through the sidecar, ensuring mTLS is used.

    Related concept

    Read the scenario before looking for a memorised answer.

  • Ensure that the GKE cluster has the Istio add-on enabled for all node pools.

    Why it's wrong here

    The add-on is not necessary if Istio is manually installed; the issue is with traffic policy.

Common exam traps

Common exam trap: answer the scenario, not the keyword

Google Cloud often tests the misconception that Istio mTLS alone is sufficient to enforce encryption at all layers, but the trap here is that sidecar injection and STRICT mode do not cover traffic that bypasses the sidecar (e.g., via hostNetwork or non-mesh ports), so a Network Policy is needed as a fallback enforcement mechanism.

Detailed technical explanation

How to think about this question

Istio mTLS in STRICT mode works by configuring the Envoy sidecar proxies to require TLS for all traffic between them, but it relies on the sidecar intercepting all pod traffic via iptables rules. If a pod uses a hostNetwork or a port that is not captured by the sidecar's iptables redirect (e.g., a NodePort or a port not in the service mesh), plaintext traffic can escape. A Kubernetes Network Policy with a rule that denies all traffic except on the Istio mTLS port (15443) or that explicitly allows only traffic from sidecar-injected pods can block these bypass paths. In practice, combining Istio mTLS with a Network Policy is a common security hardening pattern to ensure defense in depth.

KKey Concepts to Remember

  • Read the scenario before looking for a memorised answer.
  • Find the constraint that changes the correct option.
  • Eliminate answers that are true in general but not in this case.

TExam Day Tips

  • Watch for words such as best, first, most likely and least administrative effort.
  • Review why wrong options are wrong, not only why the correct option is correct.

Key takeaway

Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.

Real-world example

How this comes up in practice

A healthcare organisation deploys an application with a public-facing web tier and a private database tier. The database subnet has no public IP and only accepts connections from the web tier's security group. Questions like this test whether you can design cloud network isolation using VNets/VPCs, subnets, and security group rules.

What to study next

Got this wrong? Here's your next step.

Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.

Related practice questions

Related ACE practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

Practice this exam

Start a free ACE practice session

Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.

FAQ

Questions learners often ask

What does this ACE question test?

Configuring access and security — This question tests Configuring access and security — Read the scenario before looking for a memorised answer..

What is the correct answer to this question?

The correct answer is: Apply a Kubernetes Network Policy to deny all non-mTLS traffic. — Option C is correct because Istio mTLS in STRICT mode only enforces encryption between sidecars that are properly configured and have discovered each other via the Istio control plane. However, if a pod bypasses the sidecar (e.g., by using a hostNetwork or a non-sidecar port), or if the sidecar is not enforcing the policy due to a misconfiguration, plaintext traffic can still flow. Applying a Kubernetes Network Policy that explicitly denies all non-mTLS traffic (e.g., by blocking TCP port 80 and allowing only port 443 or the Istio mTLS port) provides a defense-in-depth layer that blocks any unencrypted communication at the network layer, regardless of sidecar behavior.

What should I do if I get this ACE question wrong?

Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.

What is the key concept behind this question?

Read the scenario before looking for a memorised answer.

About these practice questions

Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Keep practising

More ACE practice questions

Last reviewed: Jun 30, 2026

Question Discussion

Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.

Loading comments…

Sign in to join the discussion.

This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.