CCNA Configuring network security Questions — Page 2 of 2

MCQmedium

A company runs a GKE cluster in a private cluster mode (no public endpoint) in a custom VPC. The cluster nodes are in a subnet that uses a secondary IP range for pods. The company needs the pods to access an on-premises service over a Cloud VPN connection that terminates in a different region. The on-premises service IP range is 10.100.0.0/16. The VPC has a route for 10.100.0.0/16 pointing to the VPN gateway. However, pods cannot reach the on-premises service. The GKE cluster is configured with a Cloud NAT for outbound internet access. The pod IP range is 10.200.0.0/16. Which step is required to allow pod traffic to reach the on-premises network?

A.Configure Cloud NAT to also translate pod IPs to the node IPs for on-premises traffic.

B.Add a static route in the VPC for the pod IP range (10.200.0.0/16) with next hop set to the VPN gateway.

C.Disable IP masquerade in the GKE cluster to use pod IPs directly.

D.Create a firewall rule allowing traffic from the pod IP range to the on-premises IP range.

AnswerB

Correct: this ensures traffic from pods to on-premises is routed via VPN.

Why this answer

The VPC has a route for the on-premises range (10.100.0.0/16) pointing to the VPN gateway, but the GKE cluster's pod IP range (10.200.0.0/16) is not part of the VPC's primary or secondary subnet ranges. By default, GKE pods use IP addresses from a secondary IP range that is not automatically advertised over Cloud VPN. Adding a static route in the VPC for 10.200.0.0/16 with next hop set to the VPN gateway ensures that traffic from pods to the on-premises network is forwarded through the VPN tunnel, allowing the on-premises routers to learn the pod subnet and route return traffic back.

Exam trap

Google Cloud often tests the misconception that firewall rules or NAT configuration are the primary solution for connectivity issues, when in fact the missing route for the pod IP range to the VPN gateway is the root cause.

How to eliminate wrong answers

Option A is wrong because Cloud NAT is used for outbound internet access and translates pod IPs to node IPs for internet-bound traffic, not for on-premises traffic over VPN; using NAT for VPN traffic would break return routing and is unnecessary. Option C is wrong because disabling IP masquerade would cause pod traffic to use pod IPs directly, but the core issue is the lack of a route for the pod IP range to the VPN gateway, not the masquerade behavior. Option D is wrong because firewall rules control which traffic is allowed, but the problem is that traffic is not being routed to the VPN gateway at all; a firewall rule alone cannot fix a missing route.

Practice this question →

MCQeasy

Your organization has a VPC with several subnets hosting Compute Engine instances. You need to allow SSH access (port 22) to instances in the 'management' subnet from the internet, but only from the office's static IP range (203.0.113.0/24). All other ingress traffic to that subnet should be blocked. Which firewall rule configuration should you create?

A.Create an ingress rule with target tag 'management', source IP range 0.0.0.0/0, protocol tcp:22, action allow

B.Create an ingress rule with target tag 'management', source IP range 203.0.113.0/24, protocol tcp:22, action deny

C.Create an ingress rule with target tag 'management', source IP range 203.0.113.0/24, protocol tcp:22, action allow

D.Create an ingress rule with target tag 'management', source IP range 203.0.113.0/24, protocol all, action allow

AnswerC

Correct: Targets the subnet's instances via tag, allows SSH only from office IP.

Why this answer

Option C is correct because it creates an ingress firewall rule that explicitly allows TCP port 22 traffic from the office's static IP range (203.0.113.0/24) to instances tagged 'management'. In Google Cloud VPC firewall rules, the default action is to deny all ingress traffic unless an allow rule matches, so this single allow rule satisfies the requirement: only SSH from the office IP range is permitted, and all other ingress is implicitly blocked.

Exam trap

Google Cloud often tests the misconception that you need both an allow rule and a separate deny rule to block other traffic, but in Google Cloud VPC, the implicit deny all ingress rule already blocks everything not explicitly allowed, so only the allow rule is required.

How to eliminate wrong answers

Option A is wrong because it allows SSH from any source IP (0.0.0.0/0), which violates the requirement to restrict access only to the office's static IP range. Option B is wrong because it creates a deny rule for the allowed source IP range, which would block the very traffic that should be permitted; deny rules are evaluated after allow rules, but this rule would block the intended SSH access. Option D is wrong because it allows all protocols (not just TCP:22) from the office IP range, which would permit unnecessary traffic (e.g., HTTP, RDP) and violates the requirement to block all other ingress traffic to the management subnet.

Practice this question →

Multi-Selecthard

Which THREE components are required to configure VPC Flow Logs for a Compute Engine instance?

Select 3 answers

A.Enable VPC Flow Logs on the subnet

B.The VM's service account must have the compute.instances.get permission

C.A log sink to export logs to BigQuery

D.A VM with a network interface in the subnet

E.A metadata server to store logs

AnswersA, B, D

Flow logs are enabled per subnet.

Why this answer

VPC Flow Logs capture network traffic metadata at the subnet level. Enabling flow logs on the subnet (A) is the primary configuration step that activates logging for all VM instances within that subnet. The VM's service account must have the compute.instances.get permission (B) to allow the flow log agent to retrieve instance metadata required for log entries.

A VM with a network interface in the subnet (D) is necessary because flow logs are generated per network interface; without a VM in the subnet, there is no traffic to log.

Exam trap

Google Cloud often tests the misconception that a log sink or external export destination is a required component for VPC Flow Logs, when in fact the logs are natively stored in Cloud Logging and exporting is optional.

Practice this question →

MCQhard

A company has a VPC network with a default route to the internet gateway. They want all egress traffic to go through a firewall appliance instead. They create a new route with a next hop to the appliance and a priority of 500. However, traffic is still going through the internet gateway. What is the most likely reason?

A.The new route has a higher tag specification that overrides

B.The new route's destination range is not 0.0.0.0/0

C.The appliance does not have IP forwarding enabled

D.The firewall appliance is in a different network

AnswerB

The default route covers all destinations; the new route must also be 0.0.0.0/0 with a higher priority to override.

Why this answer

The default route to the internet gateway has a destination of 0.0.0.0/0. For the new route to override it, the new route must also have a destination of 0.0.0.0/0 (or a more specific prefix). If the new route's destination range is not 0.0.0.0/0, it will not match all egress traffic, and the existing default route with a lower priority (higher numerical value) will still be used for traffic that does not match the new route's destination.

Exam trap

Google Cloud often tests the misconception that a lower priority number always overrides a higher priority number, but the trap here is that the route must also have the same destination prefix (0.0.0.0/0) to override the default route; otherwise, the default route remains active for all unmatched traffic.

How to eliminate wrong answers

Option A is wrong because route tags are used for route distribution and policy-based routing, not for overriding route priority in a VPC routing table; priority (or metric) is the sole determinant of route selection among routes with the same destination prefix. Option C is wrong because IP forwarding on the appliance is required for the appliance to forward traffic, but the question states traffic is still going through the internet gateway, meaning the route to the appliance is not being used at all—IP forwarding would only matter if the route were matched. Option D is wrong because a firewall appliance in a different network would be unreachable as a next hop, but the route would still be installed; the issue is that the route's destination range does not match the traffic, not that the next hop is in a different network.

Practice this question →

MCQhard

You are a security engineer for a financial services company that processes sensitive customer data. Your architecture includes two VPCs: 'data-vpc' (10.1.0.0/16) containing BigQuery datasets and Cloud Storage buckets, and 'app-vpc' (10.2.0.0/16) containing Compute Engine instances running a customer-facing application. The application needs to read from BigQuery and write to Cloud Storage. You have configured VPC Network Peering between the VPCs. Additionally, you have set up Private Google Access on all subnets in 'data-vpc' and 'app-vpc'. The application instances cannot connect to BigQuery or Cloud Storage. You have verified that firewall rules allow egress traffic to the Google APIs IP range (199.36.153.4/30) and that DNS resolution works correctly. What is the most likely cause of the connectivity failure?

A.VPC Network Peering does not support Private Google Access.

B.Cloud NAT is not configured for 'app-vpc'.

C.The 'app-vpc' subnets do not have a default route (0.0.0.0/0) to the internet gateway.

D.Firewall rules are blocking traffic to the Google APIs IP range.

AnswerC

Private Google Access requires a default route for traffic to be sent to the internet gateway.

Why this answer

Option C is correct because Private Google Access requires a default route (0.0.0.0/0) to the internet gateway in the VPC where the Compute Engine instances reside. Without this route, traffic destined for Google APIs (including BigQuery and Cloud Storage) cannot be forwarded to the internet gateway, even if Private Google Access is enabled on the subnet. The firewall rules and DNS are correctly configured, but the missing default route prevents the egress traffic from reaching the Google API IP range (199.36.153.4/30).

Exam trap

Google Cloud often tests the misconception that Private Google Access works independently of routing, but the trap here is that candidates overlook the requirement for a default route (0.0.0.0/0) to the internet gateway, even when Private Google Access is enabled on the subnet.

How to eliminate wrong answers

Option A is wrong because VPC Network Peering does support Private Google Access; the peering itself does not interfere with Private Google Access, which is a subnet-level feature that allows instances to reach Google APIs without external IP addresses. Option B is wrong because Cloud NAT is not required for Private Google Access; Private Google Access uses the internet gateway (default route) to reach Google APIs, not NAT. Option D is wrong because the question states that firewall rules allow egress traffic to the Google APIs IP range (199.36.153.4/30), so blocking is not the issue.

Practice this question →

Multi-Selecthard

A security engineer needs to restrict outbound traffic from a VPC to only allow specific external IP ranges. Which three components must be configured? (Choose three.)

Select 3 answers

A.Cloud NAT

B.Private Google Access

C.Routes with next hop to a firewall instance

D.Firewall rules on the instance OS

E.VPC firewall rules (egress)

AnswersA, C, E

Required for private instances to reach the internet.

Why this answer

To restrict outbound traffic, you need egress firewall rules (B). If instances have no public IP, they need Cloud NAT for internet access (A). To enforce granular filtering, traffic must be routed through a firewall appliance (D).

Practice this question →

MCQhard

A company is deploying a multi-tier application on Google Cloud. The web tier must be accessible from the internet, while the application and database tiers must only be accessible from the web tier. The security team wants to use VPC firewall rules and Cloud NAT for outbound internet access from private instances. Which architecture meets these requirements with the least operational overhead?

A.Use a single subnet for all tiers. Assign public IPs to all instances. Use firewall rules to restrict access between tiers. Use a proxy VM for outbound internet from app/db tiers.

B.Create separate VPCs for each tier. Use VPC peering to connect them. Use firewall rules to allow traffic. Use a bastion host for SSH access to app/db tiers.

C.Place all tiers in the same VPC. Use firewall rules to restrict access. Assign public IPs to web tier instances and private IPs to app/db tiers. Configure Cloud NAT for app/db tiers.

D.Place web tier in a public subnet with public IPs. Place app/db tiers in private subnets with no public IPs. Use firewall rules to allow traffic from web to app, and app to db. Configure Cloud NAT for private subnets.

AnswerD

This uses public subnets for web, private subnets for app/db, firewall rules for least privilege, and Cloud NAT for outbound access.

Why this answer

Option D is correct because it uses a single VPC with separate public and private subnets, which minimizes operational overhead while meeting the security requirements. The web tier in the public subnet gets public IPs for internet access, while the app and database tiers in private subnets have no public IPs and rely on Cloud NAT for outbound internet. Firewall rules restrict traffic to only the necessary flows (web→app, app→db), and Cloud NAT provides scalable outbound connectivity without managing a proxy VM.

Exam trap

Google Cloud often tests the misconception that separate VPCs or multiple subnets are required for security, when in fact a single VPC with proper subnetting and firewall rules is simpler and meets the same security goals with less operational overhead.

How to eliminate wrong answers

Option A is wrong because assigning public IPs to all instances exposes the app and database tiers directly to the internet, violating the requirement that they only be accessible from the web tier, and using a proxy VM adds unnecessary operational overhead compared to Cloud NAT. Option B is wrong because creating separate VPCs for each tier with VPC peering adds significant complexity and operational overhead (managing peering, route tables, and firewall rules across VPCs) without any security benefit over a single VPC with proper subnetting and firewall rules. Option C is wrong because placing all tiers in the same VPC with public IPs on the web tier and private IPs on app/db tiers is a valid approach, but it fails to isolate the web tier in a public subnet; the web tier instances would still be in the same subnet as private instances, which can complicate firewall rule management and does not follow the best practice of using separate subnets for public and private tiers.

Practice this question →

MCQmedium

A company uses a hub-and-spoke VPC topology with Network Connectivity Center. The spoke VPCs need to reach the internet. Cloud NAT is configured in the hub VPC. Spoke VPCs have routes to the hub via a VPN tunnel. However, instances in spoke VPCs cannot reach the internet. Which configuration is most likely missing?

A.The spoke VPCs are not receiving a default route (0.0.0.0/0) from the hub via Cloud Router.

B.A network virtual appliance (NVA) is required in the hub for spoke internet access.

C.Firewall rules for egress internet traffic are missing in spoke VPCs.

D.Cloud NAT is not configured in the spoke VPCs.

AnswerA

Correct: route advertisement needed for spoke to send internet traffic to hub.

Why this answer

In a hub-and-spoke topology with Network Connectivity Center, spoke VPCs rely on the hub for internet access via Cloud NAT. For this to work, the spoke VPCs must have a default route (0.0.0.0/0) pointing to the hub, typically advertised by Cloud Router over the VPN tunnel. Without this route, traffic from spoke instances to the internet will not be forwarded to the hub, and thus will not reach Cloud NAT.

Exam trap

Google Cloud often tests the misconception that Cloud NAT must be deployed in each spoke VPC for internet access, but the trap here is that a centralized Cloud NAT in the hub can work for all spokes if the default route is properly advertised via BGP from the hub.

How to eliminate wrong answers

Option B is wrong because a network virtual appliance (NVA) is not required; Cloud NAT in the hub can provide internet access to spokes without an NVA, as long as routing is correctly configured. Option C is wrong because firewall rules for egress internet traffic are not the missing piece; by default, VPC firewall rules allow egress traffic, and the issue is routing, not firewall policy. Option D is wrong because Cloud NAT does not need to be configured in the spoke VPCs; the hub's Cloud NAT can serve spoke traffic if the default route points to the hub, making spoke-level NAT unnecessary.

Practice this question →

Multi-Selecteasy

A company wants to restrict access to a Cloud SQL instance so that only Compute Engine instances in a specific VPC subnet can connect. Which THREE methods can be used to achieve this? (Choose THREE.)

Select 3 answers

A.Configure authorized networks with the subnet's CIDR range (if using public IP).

B.Create a VPC firewall rule that blocks all traffic to the Cloud SQL instance's IP.

C.Enable private IP on the Cloud SQL instance and connect from instances in the same VPC.

D.Use VPC Service Controls to limit access to the Cloud SQL instance.

E.Use Cloud SQL Proxy with IAM permissions to connect from authorized clients.

AnswersA, C, E

Authorized networks allow ingress from specified public IP ranges.

Why this answer

Option A is correct because authorized networks allow you to restrict access to a Cloud SQL instance with a public IP by specifying the CIDR range of the subnet. Only traffic originating from IP addresses within that range can connect to the instance, effectively limiting access to Compute Engine instances in that subnet.

Exam trap

Google Cloud often tests the misconception that VPC firewall rules can control traffic to managed services like Cloud SQL, but in reality, Cloud SQL instances are not part of your VPC's network stack and are not subject to VPC firewall rules.

Practice this question →

MCQhard

A company has an on-premises data center connected to Google Cloud via a Dedicated Interconnect. They want to allow instances in a VPC (10.0.0.0/8) to access Google APIs (e.g., Cloud Storage) without traversing the public internet. They also want to ensure that traffic from on-premises to Google APIs uses the same private path. Which configuration is required?

A.Set up Cloud VPN and use Private Google Access on the VPC.

B.Apply VPC Service Controls and enable Private Google Access on the subnet.

C.Configure Cloud NAT on the VPC and on-premises route via the interconnect.

D.Enable Private Google Access on the VPC subnet and advertise the default route (0.0.0.0/0) from on-premises with a specific route for Google APIs (199.36.153.4/30) pointing to the interconnect.

AnswerD

Private Google Access allows VMs to reach Google APIs via private IPs; on-premises can use custom routes to reach Google APIs via the interconnect.

Why this answer

Option D is correct because it enables Private Google Access on the VPC subnet, which allows instances with private IPs to reach Google APIs without public internet. Additionally, advertising a default route (0.0.0.0/0) from on-premises via the Dedicated Interconnect ensures that on-premises traffic to Google APIs also uses the private path, while the specific route for Google APIs (199.36.153.4/30) overrides the default to direct API traffic through the interconnect, avoiding asymmetric routing.

Exam trap

The trap here is that candidates often confuse Private Google Access with Cloud NAT or VPC Service Controls, not realizing that Private Google Access requires a specific route (199.36.153.4/30) and a default route from on-premises to ensure bidirectional private connectivity over Dedicated Interconnect.

How to eliminate wrong answers

Option A is wrong because Cloud VPN is a public-internet-based encrypted tunnel, not a private path like Dedicated Interconnect, and Private Google Access alone does not route on-premises traffic via the interconnect. Option B is wrong because VPC Service Controls provide security boundaries (e.g., data exfiltration prevention) but do not enable private routing for on-premises traffic to Google APIs. Option C is wrong because Cloud NAT is used for outbound internet access from private instances, not for private access to Google APIs, and it does not address on-premises routing requirements.

Practice this question →

Multi-Selecthard

Your company has a VPC with multiple subnets. You have deployed a set of Compute Engine instances that must communicate with each other over TCP port 4444. The instances are tagged with 'app-tier'. You need to ensure that only these instances can communicate on this port. Which THREE of the following steps are necessary to achieve this?

Select 3 answers

A.Remove the default allow egress rule that allows all outbound traffic

B.Create an egress firewall rule that allows TCP 4444 from target tag 'app-tier' to source tag 'app-tier'

C.Create a VPC firewall rule to deny all egress traffic from the VPC

D.Create an ingress firewall rule that allows TCP 4444 from source tag 'app-tier' to target tag 'app-tier'

E.Apply the 'app-tier' tag to all instances that need to communicate

AnswersB, D, E

This rule allows outbound traffic on port 4444 from instances with the tag 'app-tier' to instances with the same tag.

Why this answer

Option B is correct because egress firewall rules control outbound traffic from instances. By creating an egress rule allowing TCP 4444 from source tag 'app-tier' to destination tag 'app-tier', you ensure that only instances with the 'app-tier' tag can send traffic on that port to other 'app-tier' instances, while all other outbound traffic is implicitly denied by the default deny egress rule (unless overridden by a higher-priority allow rule). This restricts communication to the intended group.

Exam trap

Google Cloud often tests the misconception that egress rules are unnecessary for restricting inter-instance communication, but in GCP, both ingress and egress rules are required to fully control traffic flow, as egress rules govern outbound packets from the source instance.

Practice this question →