Custom VPC creation in GCP - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
When creating a custom Virtual Private Cloud (VPC) in GCP, it is important to understand how the time to complete the setup changes as you add more components.
We want to know how the number of steps or API calls grows when we create more subnets or firewall rules.
Analyze the time complexity of the following operation sequence.
# Create a custom VPC network
gcloud compute networks create my-vpc --subnet-mode=custom
# Create multiple subnets in the VPC
for i in $(seq 1 n); do
gcloud compute networks subnets create subnet-$i --network=my-vpc --region=region-$i --range=10.$i.0.0/24
done
# Create firewall rules for the VPC
for i in $(seq 1 m); do
gcloud compute firewall-rules create fw-rule-$i --network=my-vpc --allow tcp:80
done
This sequence creates a custom VPC, then adds multiple subnets and firewall rules to it.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Creating subnets and firewall rules via API calls.
- How many times: Subnet creation happens n times; firewall rule creation happens m times.
Each subnet and firewall rule requires a separate API call, so the total number of calls grows as you add more.
| Input Size (n + m) | Approx. Api Calls/Operations |
|---|---|
| 10 | About 10 calls (e.g., 5 subnets + 5 firewall rules) |
| 100 | About 100 calls (e.g., 50 subnets + 50 firewall rules) |
| 1000 | About 1000 calls (e.g., 500 subnets + 500 firewall rules) |
Pattern observation: The total work grows directly with the number of subnets and firewall rules you create.
Time Complexity: O(n + m)
This means the time to create the VPC setup grows linearly with the number of subnets and firewall rules added.
[X] Wrong: "Creating one big VPC network means all subnets and rules are created instantly in one step."
[OK] Correct: Each subnet and firewall rule requires its own API call and setup time, so the total time grows with how many you add.
Understanding how the number of resources affects setup time helps you plan and explain cloud infrastructure tasks clearly and confidently.
"What if we created all subnets in parallel instead of one after another? How would the time complexity change?"
Practice
Custom VPC in Google Cloud Platform?Solution
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.Step 2: Eliminate wrong options
Custom VPC does not disable traffic, default firewall rules exist regardless, free internet requires configuration.Final Answer:
You can define your own IP address ranges and subnets. -> Option AQuick Check:
Custom VPC = Custom IP ranges [OK]
- Confusing default VPC with custom VPC
- Thinking firewall rules are auto-created
- Assuming internet access is automatic
gcloud command correctly creates a custom VPC named my-vpc with no automatic subnet creation?Solution
Step 1: Identify subnet mode for custom VPC
Custom VPC requires the flag--subnet-mode=customto avoid automatic subnet creation.Step 2: Evaluate options
--subnet-mode=auto creates automatic subnets. --auto-create-subnetworks uses invalid syntax. --no-subnet-mode does not exist.Final Answer:
gcloud compute networks create my-vpc --subnet-mode=custom -> Option DQuick Check:
Custom VPC uses --subnet-mode=custom [OK]
- Using --subnet-mode=auto instead of custom
- Using invalid flags like --no-subnet-mode
- Assuming subnets are created automatically
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?Solution
Step 1: Read the subnet creation command
The command specifies--range=10.0.1.0/24which sets the IP range for the subnet.Step 2: Match the CIDR range
10.0.1.0/24 matches the exact CIDR range given in the command.Final Answer:
10.0.1.0/24 -> Option CQuick Check:
Subnet range = 10.0.1.0/24 [OK]
- Confusing VPC range with subnet range
- Picking wrong CIDR block from options
- Ignoring the --range parameter
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?
Solution
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.Step 2: Check other options
Region and network existence errors produce different messages; --subnet-mode is for network creation, not subnet.Final Answer:
The subnet range 10.0.1.0/24 overlaps with another subnet in the same VPC. -> Option AQuick Check:
Overlapping CIDR causes subnet creation error [OK]
- Assuming region is invalid without checking
- Confusing network creation flags with subnet flags
- Ignoring existing subnet CIDR ranges
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/24Which sequence of
gcloud commands correctly creates this setup?Solution
Step 1: Create the VPC with custom subnet mode
The VPC must be created with--subnet-mode=customto allow manual subnet creation.Step 2: Create subnets with correct regions and CIDR ranges
Subnets must be created with specified regions and matching CIDR ranges as per requirements.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.Final Answer:
Correct sequence with custom subnet mode and matching subnet ranges -> Option BQuick 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]
- Using auto subnet mode when manual subnets needed
- Swapping subnet CIDR ranges by mistake
- Omitting --subnet-mode flag on VPC creation
