Troubleshoot a Broken GCP Web Server

Diagnose and fix a misconfigured firewall on a GCP Compute Engine VM.

Introduction

30 Second Summary

When a website goes down, someone has to figure out why and bring it back online. That's the core skill of a cloud support engineer.

In this project, you will create a web server on Google Cloud Platform, simulate a real-world outage by misconfiguring its firewall, then systematically diagnose and fix the issue.

What You'll Build

A live web server on GCP that you'll intentionally break and repair using the same troubleshooting process cloud support engineers follow every day.

By the end of this project, you'll have:

  • A live web server running on GCP Compute Engine that you created from the command line.
  • Hands-on experience navigating the Google Cloud Console and Cloud Shell.
  • Practice diagnosing and fixing VPC firewall rules, a top interview topic for cloud support roles.
  • Secret Mission: Diagnose a blocked SSH connection using Cloud Logging audit trails.

Are there any prerequisites?

You'll need a Google account and a credit or debit card for identity verification when signing up for the GCP Free Trial. You will NOT be charged. The trial gives you $300 in free credits for 90 days.

All work happens in your browser using Cloud Shell, so no local software installation is needed.

Set Up Your GCP Free Trial

Before you can build and troubleshoot a web server, you need access to Google Cloud Platform. GCP provides virtual machines, networking, and all the infrastructure tools that cloud support engineers use daily.

In this step, you'll sign up for the GCP Free Trial, verify your account is active, and open Cloud Shell so you have a command-line terminal ready in your browser.

In this step, get ready to:
  • Sign up for the GCP Free Trial with $300 in free credits.
  • Verify your account is active in the Google Cloud Console.
  • Open Cloud Shell and confirm it is connected to your project.
Sign up for GCP Free Trial

The GCP Free Trial gives new customers $300 in free credits to spend over 90 days. You need a Google account and a credit or debit card for identity verification. Google will not charge your card during the trial.

  • Open a new browser tab and navigate to cloud.google.com/free.
  • Click Get Started for Free.
  • Sign in with your Google account.
  • Select your country from the dropdown.
  • Accept the Terms of Service.
  • Enter your credit or debit card details for identity verification.
  • Complete the signup process to activate your trial.

Will I be charged?

No. Google uses your card solely for identity verification. You will not be billed for any Google Cloud usage during your Free Trial.

The trial gives you $300 in free credits valid for 90 days. Your account auto-closes at the end of the trial unless you manually upgrade to a paid account.

Seeing a payment verification issue?

Make sure your card supports international transactions. Google may place a small temporary hold that is fully refunded after verification.

If your card is declined, try a different Visa or Mastercard. Help me troubleshoot my GCP signup

Verify your account is active

After completing signup, you land in the Google Cloud Console. This is the web-based dashboard where you manage all your cloud resources.

  • Look for the free trial credit banner at the top of the page showing your $300 credit balance and remaining days.
  • Check that the project dropdown at the top of the page shows My First Project. This is the default project Google creates for you automatically.

What should I see?

At the top of the Google Cloud Console, you should see a banner displaying your remaining credit and trial days. The project selector in the top toolbar should say My First Project.

Open Cloud Shell

Cloud Shell is a free Linux terminal built into the Google Cloud Console. It comes pre-installed with the gcloud CLI, so you do not need to install anything on your computer.

  • In the top-right toolbar of the Google Cloud Console, click the terminal icon (it looks like >_).
  • Wait a few seconds for Cloud Shell to provision and open at the bottom of your browser.

What is Cloud Shell?

Cloud Shell is a browser-based terminal connected directly to your GCP project. It already has the gcloud command-line tool installed and authenticated with your account. No local setup required.

  • Confirm Cloud Shell is connected to your project by running this command:
gcloud config list

What does this command do?

The gcloud config list command displays your active configuration properties. It shows which Google account you are authenticated as and which project is currently active.

You should see a [core] section in the output listing your account (your Google email) and project (your project ID).

Not seeing your project in the output?

If the output does not show a project, Cloud Shell may not be linked to your default project yet. Try clicking the project name in the top toolbar of the Console and selecting My First Project, then run the command again.

If Cloud Shell did not open at all, make sure you clicked the correct icon (terminal-shaped, top-right corner). Help me get Cloud Shell working

Your GCP environment is ready. Next up, you'll create a virtual machine and install a web server on it.

Create a Virtual Machine

Your GCP account is ready and Cloud Shell is open. Now it is time to create the actual infrastructure you will troubleshoot later.

In this step, you will spin up a Compute Engine virtual machine, connect to it over SSH, and install a web server. This gives you a live website running on GCP that you can break and fix in later steps.

In this step, get ready to:
  • Create a Compute Engine VM from the command line.
  • SSH into your VM using Cloud Shell.
  • Install Apache and verify a live web page.
Create the VM using Cloud Shell

A virtual machine is a computer running in the cloud. You are about to create one with a single command.

  • Create a small virtual machine in the us-central1 region by running this command in Cloud Shell:
gcloud compute instances create web-server-1 \
  --zone=us-central1-a \
  --machine-type=e2-micro \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --tags=http-server

What does this command do?

  • web-server-1 is the name you are giving to this VM.
  • --zone=us-central1-a places the VM in a specific data centre location.
  • --machine-type=e2-micro picks the smallest (and cheapest) general-purpose machine.
  • --image-family=debian-12 installs Debian Linux as the operating system.
  • --tags=http-server applies a network tag you will use later to target firewall rules at this VM.
  • Wait about 30 seconds for the VM to be created.
  • You should see a table in the output with columns including NAME, ZONE, MACHINE_TYPE, INTERNAL_IP, EXTERNAL_IP, and STATUS.
  • Copy the EXTERNAL_IP value from the output. You will need this IP address soon.

Don't see the table or got an error?

  • If you see a permission error, make sure your Cloud Shell session is connected to the correct project. Run gcloud config list to confirm.
  • If the Compute Engine API is not enabled, Cloud Shell may prompt you to enable it. Type Y to approve.

Still stuck? Help me fix this VM creation error.

SSH into your VM

Your VM is running, but you need to get inside it to install software. SSH is how you securely connect to a remote machine from the command line.

  • Connect to your new VM by running this command:
gcloud compute ssh web-server-1 --zone=us-central1-a

What will I be prompted about?

Because this is your first time connecting, Cloud Shell needs to generate an SSH key pair. You may be prompted to confirm. Type Y if asked. You can also press Enter through any passphrase prompts to leave the passphrase empty.

Once connected, your terminal prompt changes to show you are now inside the VM (you will see something like username@web-server-1).

  • Confirm your terminal prompt now shows web-server-1 in it. This means you are inside the VM.

Connection timed out?

  • The VM may still be booting. Wait 30 seconds and try the command again.
  • Make sure you typed the zone exactly as us-central1-a.

Still can't connect? Help me debug this SSH connection issue.

Install and start a web server

Now that you are inside the VM, you will install Apache. This is one of the most popular web servers in the world. It will serve a web page to anyone who visits your VM's IP address.

  • Install Apache, create a custom web page, and check the server status by running these commands:
sudo apt update && sudo apt install -y apache2
echo "<h1>Hello from WALT Labs interview prep!</h1><p>Server: web-server-1</p>" | sudo tee /var/www/html/index.html
sudo systemctl status apache2

What do these commands do?

  • sudo apt update refreshes the list of available packages on Debian Linux.
  • sudo apt install -y apache2 installs the Apache web server. The -y flag automatically confirms the installation.
  • The echo command creates a simple HTML page at /var/www/html/index.html. This is the default location Apache serves files from.
  • sudo systemctl status apache2 checks whether Apache is running. You should see active (running) in the output.
  • Look at the output of the last command. You should see a green dot and the text active (running). This confirms your web server is live.

Not seeing active (running)?

  • If you see an error about packages, your VM may not have internet access. Run ping -c 2 google.com to test connectivity.
  • If the status shows inactive or failed, try starting Apache manually with sudo systemctl start apache2.

Still stuck? Help me get Apache running on my VM.

Your web server is running inside the VM. Next up, you will open a port in the firewall so that anyone on the internet can actually visit your page.

Allow Web Traffic and Verify

Your web server is running inside the VM, but nobody on the internet can reach it yet.

By default, GCP's VPC network blocks all incoming traffic unless you explicitly allow it. In this step, you'll create a firewall rule that opens port 80 for HTTP traffic, then verify your website loads in a browser.

In this step, get ready to:
  • Create a firewall rule that allows web traffic to your VM.
  • Test your live website in a browser.
Create a firewall rule to allow HTTP traffic

A VPC firewall rule controls which traffic is allowed into or out of your network. You need one that lets HTTP traffic (port 80) reach your VM.

  • Create the firewall rule by running this command in Cloud Shell:
gcloud compute firewall-rules create allow-http \
  --direction=INGRESS \
  --priority=1000 \
  --network=default \
  --action=ALLOW \
  --rules=tcp:80 \
  --target-tags=http-server

What does this command do?

  • allow-http is the name of the rule you're creating.
  • --direction=INGRESS means this rule applies to incoming traffic (from the internet toward your VM).
  • --rules=tcp:80 specifies that only TCP traffic on port 80 (the standard web port) is affected.
  • --target-tags=http-server means only VMs with the tag http-server receive this traffic. Your VM has that tag.
  • Wait a few seconds for the command to finish. You should see output confirming the rule was created, showing the rule name and its properties.

Seeing an error about duplicate resource?

If you see a message saying the resource already exists, a rule named allow-http was already created in a previous attempt. You can move on to the next substep.

If you see a permissions error, make sure Cloud Shell is connected to your project. Run gcloud config list to confirm.

Still stuck? Help me debug this firewall rule creation error in GCP Cloud Shell.

Test your website

Now that the firewall is open, you can access your web server from any browser. First, you need your VM's public IP address.

  • Get your VM's external IP address by running this command:
gcloud compute instances describe web-server-1 --zone=us-central1-a --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
  • Copy the IP address that appears in the output.
  • Open a new browser tab.
  • Paste the IP address into the browser's address bar and press Enter.

You should see your custom webpage displaying "Hello from WALT Labs interview prep!" with "Server: web-server-1" below it.

Page not loading or timing out?

  • Make sure you're using just the IP address in the browser (no extra characters or spaces). It should look like a set of four numbers separated by dots.
  • Check that your browser isn't adding https:// in front of the IP. Your server only supports http:// (no 's'). Try typing http:// before your IP manually.
  • If the page still times out, the firewall rule may not have been created. Run gcloud compute firewall-rules list and look for allow-http in the output.

Need more help? Help me figure out why my GCP web server page isn't loading in the browser.

What's in place right now?

You now have three pieces working together to serve your website.

  • A VM (Compute Engine) running Apache on port 80.
  • A network (the default VPC) connecting the VM to the internet.
  • A firewall rule (allow-http) that permits incoming web traffic to reach tagged VMs.

If any one of these is missing or misconfigured, the website goes down. That's exactly what you'll test in the next step.

Your website is live and publicly accessible. Next up, you'll simulate a real-world incident by breaking the firewall rule and diagnosing the outage like a cloud support engineer.

Break It (Simulate an Incident)

Your web server is live and accessible to the world. Time to break it.

In cloud support, firewall misconfigurations are one of the most common causes of outages. You'll simulate exactly this scenario by deleting the rule that allows web traffic to your VM.

In this step, get ready to:
  • Delete the firewall rule allowing web traffic.
  • Verify the website is unreachable.
  • Document the incident symptom for diagnosis.
Delete the firewall rule

Imagine a colleague has just made a mistake. They deleted a critical firewall rule without realizing it controlled web traffic to a production server.

  • Simulate this misconfiguration by deleting the allow-http rule in Cloud Shell:
gcloud compute firewall-rules delete allow-http --quiet

The --quiet flag suppresses the confirmation prompt, so the command completes silently. You'll confirm the deletion worked in the next substep by checking the website.

Getting a 'not found' error?

If you see an error mentioning the resource was not found, you may have already deleted the rule in a previous attempt. This is fine. Continue to the next substep.

Why did my firewall rule deletion fail?

Verify the site is down
  • Switch to the browser tab where your website was loading (the one showing your VM's external IP address).
  • Refresh the page.

The page fails to load. You'll see a timeout or a connection refused error instead of your webpage.

What just happened?

By deleting the allow-http firewall rule, you removed the only path for web traffic (port 80) to reach your VM.

The VM and Apache are both still running perfectly. The VPC network is simply blocking all incoming HTTP requests before they reach the server.

Document the symptom

Before troubleshooting, a support engineer always documents what they observe first. This creates a starting point for systematic diagnosis and prevents jumping to conclusions.

  • Open a text file or note-taking app on your computer.
  • Write down your incident symptom: "Client reports website at (your VM's IP) is unreachable. Page times out in browser."
  • Replace "(your VM's IP)" with the actual external IP address of your VM.

Why document symptoms first?

Cloud support engineers document symptoms before investigating to create a paper trail and prevent bias. You'll use this observation as the starting point for systematic diagnosis in the next step.

This symptom statement also becomes the "Situation" in your STAR interview answer. Interviewers want to see that you approach problems methodically, not by guessing.

Your incident is live and documented. Next up, you'll put on your support engineer hat and systematically track down the root cause.

Diagnose and Fix the Issue

The incident is live. A client reported that the website is unreachable, and you documented the symptom in the previous step.

In this step, you'll follow the same systematic process that cloud support engineers use daily. You'll check each layer in order: compute, application, then network.

In this step, get ready to:
  • Rule out a server crash by checking the VM status.
  • Investigate the network layer by reviewing firewall rules.
  • Fix the root cause and restore the website.
Check the VM is running

The simplest explanation for an unreachable website is a crashed server. Start by ruling that out.

  • Check if your Compute Engine VM is still running by running this command in Cloud Shell:
gcloud compute instances describe web-server-1 --zone=us-central1-a --format='get(status)'

You should see RUNNING in the output. The VM is healthy.

  • Next, check if Apache is still serving content by running this command:
gcloud compute ssh web-server-1 --zone=us-central1-a --command="sudo systemctl status apache2"

You should see Active: active (running) in the output. Apache is fine.

What did you just rule out?

You checked the compute layer (is the VM on?) and the application layer (is Apache running?). Both are healthy.

This means the problem is not the server or the web application. The issue must be in the network layer, which controls whether traffic can actually reach your VM.

Check the firewall rules

VPC firewall rules control which traffic is allowed to reach your VM. If a rule is missing or misconfigured, traffic gets silently dropped.

  • List all firewall rules in your network by running this command in Cloud Shell:
gcloud compute firewall-rules list --format="table(name, direction, allowed, targetTags)"

Look at the output carefully. You'll notice there is no rule allowing TCP port 80 to the http-server tag.

What does this mean?

The output shows every active firewall rule for your default VPC network. Without a rule that allows TCP port 80 (HTTP traffic) to reach VMs tagged with http-server, all incoming web requests are blocked.

Root cause identified: the deleted firewall rule is preventing all web traffic from reaching your VM.

The three-layer approach

This compute, application, network sequence is the standard troubleshooting method for connectivity issues in cloud support. Memorize it for your interview.

Recreate the firewall rule

You've identified the problem. The firewall rule that allowed HTTP traffic on port 80 is gone. Time to fix it.

  • Recreate the missing firewall rule by running this command in Cloud Shell:
gcloud compute firewall-rules create allow-http \
  --direction=INGRESS \
  --priority=1000 \
  --network=default \
  --action=ALLOW \
  --rules=tcp:80 \
  --target-tags=http-server

What does this command do?

This recreates the exact firewall rule you deleted in the previous step. It allows incoming (INGRESS) TCP traffic on port 80 to reach any VM tagged with http-server in the default network.

Priority 1000 is the standard priority for custom rules. Lower numbers mean higher priority.

  • Switch to your browser tab with the VM's IP address.
  • Refresh the page.

You should see your "Hello from WALT Labs interview prep!" page again. Your website is back online.

Still seeing a timeout?

  • Firewall rules can take 10-15 seconds to propagate. Wait a moment and refresh again.
  • Make sure the command completed without errors in Cloud Shell.
  • Verify you're visiting http:// (not https://) followed by your VM's IP address.

Help me troubleshoot why my website is still unreachable after recreating the firewall rule.

You just resolved your first cloud support incident. You diagnosed the issue systematically and fixed the root cause.

Secret mission

Diagnose a Blocked SSH Connection

A second incident has landed in your queue. A colleague reports they can't SSH into a different VM. Can you diagnose the root cause using the same systematic approach you just practiced, and then investigate the change using Cloud Logging?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Your GCP Free Trial covers all resources in this project. You will not be charged unless you manually upgrade to a paid account.

Cost warning

Your Free Trial auto-closes after 90 days or $300 in credit usage. You will not be charged unless you manually upgrade to a paid account.

If you do upgrade later, e2-micro VMs cost approximately $0.01/hour each. Stopped VMs do not incur compute charges but their disks still cost a small amount.

Resources you used:

  • Compute Engine VM: web-server-1 (us-central1-a).
  • Compute Engine VM: app-server-1 (us-central1-a).
  • Firewall rule: allow-http (TCP port 80).
  • Firewall rule: allow-ssh (TCP port 22).

Keep everything running

No action needed. Choose this if you want to keep practicing with your VMs or revisit the troubleshooting steps.

  • Your Free Trial gives you $300 in credit for 90 days. The e2-micro VMs cost approximately $0.01/hour each, so your credit covers months of usage.
  • Your account auto-closes at the end of the trial. You will not be charged unless you manually upgrade.
  • You can continue to SSH into your VMs and experiment with firewall rules at any time.

Pause - I'll come back to this later

Stop your VMs to save credit while keeping your setup intact. Stopped VMs do not incur compute charges.

  • Stop both VMs by running these commands in Cloud Shell:
gcloud compute instances stop web-server-1 --zone=us-central1-a
gcloud compute instances stop app-server-1 --zone=us-central1-a
  • Your firewall rules and VM configurations remain saved. When you're ready to resume, start the VMs again with:
gcloud compute instances start web-server-1 --zone=us-central1-a
gcloud compute instances start app-server-1 --zone=us-central1-a

Delete - I don't want to use this again

Remove all project resources completely. Run these commands in Cloud Shell:

  • Delete both VMs:
gcloud compute instances delete web-server-1 --zone=us-central1-a --quiet
gcloud compute instances delete app-server-1 --zone=us-central1-a --quiet
  • Delete the firewall rules:
gcloud compute firewall-rules delete allow-http --quiet
gcloud compute firewall-rules delete allow-ssh --quiet
  • After running these commands, all resources created during this project are removed. Your GCP Free Trial account remains active for other projects.

Nice Work!

Nice Work!

You just completed your first cloud support incident from start to finish. You built a live web server on GCP, broke it on purpose, and fixed it using the same systematic process real cloud support engineers follow every day.

You've learned how to:

  • Create and configure a Compute Engine VM with an Apache web server using Cloud Shell and the gcloud CLI.
  • Control network traffic with VPC firewall rules, including creating, deleting, and listing rules that target tagged instances.
  • Systematically diagnose a connectivity issue by checking the compute layer, then the application layer, then the network layer to isolate the root cause and fix it.
  • Secret Mission: Investigated a blocked SSH connection using Cloud Logging audit trails and documented the incident in STAR format for interview readiness.

Ready to quiz yourself?