Custom VPC creation in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

VPC Subnet Allocation Strategy

You create a custom VPC in Google Cloud with three subnets in different regions. Each subnet has a CIDR block:

• Subnet A: 10.0.1.0/24
• Subnet B: 10.0.2.0/24
• Subnet C: 10.0.3.0/24

What is the total number of usable IP addresses across all subnets?

A 1024 usable IP addresses

B 753 usable IP addresses

C 765 usable IP addresses

D 750 usable IP addresses

💡 Hint

Each /24 subnet has 256 IP addresses, but some are reserved by Google Cloud.

Each /24 subnet has 256 IPs. Google Cloud reserves 5 IPs per subnet (network ID, broadcast address, and 3 for infrastructure), so usable IPs per subnet = 256 - 5 = 251. For 3 subnets: 251 * 3 = 753 usable IPs.

❓ Configuration

intermediate

Firewall Rule Priority Impact

You create two firewall rules in a custom VPC:

• Rule 1: Priority 1000, allows TCP port 22 from any source
• Rule 2: Priority 500, denies all ingress traffic

What will happen when a VM in this VPC receives a TCP connection on port 22?

A The connection is denied because deny rule has lower priority number

B The connection is allowed because allow rule has higher priority number

C The connection is denied because deny rule has higher priority number

D The connection is allowed because allow rule has lower priority number

💡 Hint

Lower priority number means higher priority in firewall rules.

Firewall rules with lower priority numbers are evaluated first. Rule 2 has priority 500 (higher priority) and denies all ingress traffic, so it blocks the connection before Rule 1 can allow it.

❓ security

advanced

Private Google Access Configuration

You have a custom VPC with private subnets that do not have external IP addresses. You want VMs in these subnets to access Google APIs securely without using public IPs.

Which configuration enables this?

A Create a Cloud NAT gateway and route traffic through it

B Assign external IPs to the VMs

C Enable Private Google Access on the subnet

D Use a VPN to connect to Google APIs

💡 Hint

Private Google Access allows VMs without external IPs to reach Google APIs.

Enabling Private Google Access on the subnet allows VMs without external IPs to access Google APIs securely over internal IPs. Cloud NAT is for internet access, not Google APIs specifically.

❓ service_behavior

advanced

Impact of Overlapping CIDR Blocks

You create two custom VPCs in the same project with overlapping CIDR blocks: 10.0.0.0/16 for both.

You try to create a VPC peering connection between them. What will happen?

A Peering connection fails due to overlapping IP ranges

B Peering connection is created successfully without issues

C Peering connection is created but traffic is blocked

D Peering connection is created but only one VPC can route traffic

💡 Hint

VPC peering requires non-overlapping IP ranges.

Google Cloud does not allow VPC peering between networks with overlapping IP ranges to avoid routing conflicts.

✅ Best Practice

expert

Designing a Highly Available Custom VPC

You need to design a custom VPC for a critical application that must remain available even if one region fails. Which design approach best supports this requirement?

A Create multiple VPCs in different regions and connect them with VPN

B Create a single subnet in one region with multiple zones

C Use a single region with a large subnet and rely on Cloud Load Balancing

D Create subnets in multiple regions and deploy resources redundantly

💡 Hint

High availability across regions requires resources in multiple regions.

Creating subnets in multiple regions and deploying resources redundantly ensures availability if one region fails. Single region or multiple VPCs with VPN do not provide seamless regional failover.

Practice

1. What is the main advantage of creating a Custom VPC in Google Cloud Platform?

easy

A. You can define your own IP address ranges and subnets.

B. It automatically creates default firewall rules.

C. It provides free internet access without configuration.

D. It disables all network traffic by default.

Solution

1. Step 1: Understand Custom VPC purpose

   A Custom VPC allows you to design your network with your own IP ranges and subnets, unlike default VPCs which have preset ranges.

2. Step 2: Eliminate wrong options

   Custom VPC does not disable traffic, default firewall rules exist regardless, free internet requires configuration.

3. Final Answer:

   You can define your own IP address ranges and subnets. -> Option A

4. Quick Check:

   Custom VPC = Custom IP ranges [OK]

Hint: Custom VPC means you pick your IP ranges [OK]

Common Mistakes:

• Confusing default VPC with custom VPC
• Thinking firewall rules are auto-created
• Assuming internet access is automatic

2. Which gcloud command correctly creates a custom VPC named my-vpc with no automatic subnet creation?

easy

A. gcloud compute networks create my-vpc --subnet-mode=auto

B. gcloud compute networks create my-vpc --auto-create-subnetworks

C. gcloud compute networks create my-vpc --no-subnet-mode

D. gcloud compute networks create my-vpc --subnet-mode=custom

Solution

1. Step 1: Identify subnet mode for custom VPC

   Custom VPC requires the flag --subnet-mode=custom to avoid automatic subnet creation.

2. Step 2: Evaluate options

   --subnet-mode=auto creates automatic subnets. --auto-create-subnetworks uses invalid syntax. --no-subnet-mode does not exist.

3. Final Answer:

   gcloud compute networks create my-vpc --subnet-mode=custom -> Option D

4. Quick Check:

   Custom VPC uses --subnet-mode=custom [OK]

Hint: Use --subnet-mode=custom to create custom VPC [OK]

Common Mistakes:

• Using --subnet-mode=auto instead of custom
• Using invalid flags like --no-subnet-mode
• Assuming subnets are created automatically

3. Given this command:

gcloud compute networks subnets create subnet-1 --network=my-vpc --region=us-central1 --range=10.0.1.0/24

What is the CIDR range assigned to subnet-1?

medium

A. 10.0.0.0/16

B. 192.168.1.0/24

C. 10.0.1.0/24

D. 10.1.0.0/24

Solution

1. Step 1: Read the subnet creation command

   The command specifies --range=10.0.1.0/24 which sets the IP range for the subnet.

2. Step 2: Match the CIDR range

   10.0.1.0/24 matches the exact CIDR range given in the command.

3. Final Answer:

   10.0.1.0/24 -> Option C

4. Quick Check:

   Subnet range = 10.0.1.0/24 [OK]

Hint: Look for --range flag for subnet CIDR [OK]

Common Mistakes:

• Confusing VPC range with subnet range
• Picking wrong CIDR block from options
• Ignoring the --range parameter

4. You ran this command to create a subnet:

gcloud compute networks subnets create subnet-2 --network=my-vpc --region=us-east1 --range=10.0.1.0/24

But you get an error saying the IP range overlaps with an existing subnet. What is the likely cause?

medium

A. The subnet range 10.0.1.0/24 overlaps with another subnet in the same VPC.

B. The region us-east1 is invalid for subnet creation.

C. The network my-vpc does not exist.

D. The command is missing the --subnet-mode flag.

Solution

1. Step 1: Understand the error message

   The error about overlapping IP range means the subnet's CIDR block conflicts with an existing subnet in the same VPC.

2. Step 2: Check other options

   Region and network existence errors produce different messages; --subnet-mode is for network creation, not subnet.

3. Final Answer:

   The subnet range 10.0.1.0/24 overlaps with another subnet in the same VPC. -> Option A

4. Quick Check:

   Overlapping CIDR causes subnet creation error [OK]

Hint: Check subnet CIDR overlaps before creating [OK]

Common Mistakes:

• Assuming region is invalid without checking
• Confusing network creation flags with subnet flags
• Ignoring existing subnet CIDR ranges

5. You want to create a custom VPC named prod-vpc with two subnets:
- subnet-a in us-west1 with range 10.10.1.0/24
- subnet-b in us-east1 with range 10.10.2.0/24
Which sequence of gcloud commands correctly creates this setup?

hard

A. 1) gcloud compute networks create prod-vpc --subnet-mode=auto
2) gcloud compute networks subnets create subnet-a --network=prod-vpc --region=us-west1 --range=10.10.1.0/24
3) gcloud compute networks subnets create subnet-b --network=prod-vpc --region=us-east1 --range=10.10.2.0/24

B. 1) gcloud compute networks create prod-vpc --subnet-mode=custom
2) gcloud compute networks subnets create subnet-a --network=prod-vpc --region=us-west1 --range=10.10.1.0/24
3) gcloud compute networks subnets create subnet-b --network=prod-vpc --region=us-east1 --range=10.10.2.0/24

C. 1) gcloud compute networks create prod-vpc
2) gcloud compute networks subnets create subnet-a --network=prod-vpc --region=us-west1 --range=10.10.1.0/24
3) gcloud compute networks subnets create subnet-b --network=prod-vpc --region=us-east1 --range=10.10.2.0/24

D. 1) gcloud compute networks create prod-vpc --subnet-mode=custom
2) gcloud compute networks subnets create subnet-a --network=prod-vpc --region=us-west1 --range=10.10.2.0/24
3) gcloud compute networks subnets create subnet-b --network=prod-vpc --region=us-east1 --range=10.10.1.0/24

Solution

1. Step 1: Create the VPC with custom subnet mode

   The VPC must be created with --subnet-mode=custom to allow manual subnet creation.

2. Step 2: Create subnets with correct regions and CIDR ranges

   Subnets must be created with specified regions and matching CIDR ranges as per requirements.

3. Step 3: Verify order and correctness

   1) gcloud compute networks create prod-vpc --subnet-mode=custom 2) gcloud compute networks subnets create subnet-a --network=prod-vpc --region=us-west1 --range=10.10.1.0/24 3) gcloud compute networks subnets create subnet-b --network=prod-vpc --region=us-east1 --range=10.10.2.0/24 correctly creates the VPC first, then subnets with correct ranges and regions. 1) gcloud compute networks create prod-vpc --subnet-mode=auto 2) gcloud compute networks subnets create subnet-a --network=prod-vpc --region=us-west1 --range=10.10.1.0/24 3) gcloud compute networks subnets create subnet-b --network=prod-vpc --region=us-east1 --range=10.10.2.0/24 uses auto subnet mode which auto-creates subnets, conflicting with manual subnet creation. 1) gcloud compute networks create prod-vpc 2) gcloud compute networks subnets create subnet-a --network=prod-vpc --region=us-west1 --range=10.10.1.0/24 3) gcloud compute networks subnets create subnet-b --network=prod-vpc --region=us-east1 --range=10.10.2.0/24 misses subnet mode flag. 1) gcloud compute networks create prod-vpc --subnet-mode=custom 2) gcloud compute networks subnets create subnet-a --network=prod-vpc --region=us-west1 --range=10.10.2.0/24 3) gcloud compute networks subnets create subnet-b --network=prod-vpc --region=us-east1 --range=10.10.1.0/24 swaps CIDR ranges between subnets.

4. Final Answer:

   Correct sequence with custom subnet mode and matching subnet ranges -> Option B

5. Quick Check:

   Custom VPC + correct subnet ranges = 1) gcloud compute networks create prod-vpc --subnet-mode=custom 2) gcloud compute networks subnets create subnet-a --network=prod-vpc --region=us-west1 --range=10.10.1.0/24 3) gcloud compute networks subnets create subnet-b --network=prod-vpc --region=us-east1 --range=10.10.2.0/24 [OK]

Hint: Create VPC with --subnet-mode=custom before adding subnets [OK]

Common Mistakes:

• Using auto subnet mode when manual subnets needed
• Swapping subnet CIDR ranges by mistake
• Omitting --subnet-mode flag on VPC creation