Bird
Raised Fist0
GCPcloud~5 mins

High availability configuration in GCP - Commands & Configuration

Choose your learning style10 modes available
LearnWhyDeepVisualTryChallengeProjectRecallTime
Introduction
High availability means making sure your app or service keeps working even if some parts fail. It solves the problem of downtime by spreading resources across multiple places so if one fails, others take over.
When you want your website to stay online even if one server crashes
When you run a database that must never lose data or stop responding
When you deploy an app that users rely on 24/7 without interruptions
When you want to avoid losing customer trust due to service outages
When you need to handle sudden spikes in traffic without slowing down
Config File - main.tf
main.tf
provider "google" {
  project = "example-project"
  region  = "us-central1"
}

resource "google_compute_instance_group_manager" "ha_instance_group" {
  name               = "ha-instance-group"
  base_instance_name = "ha-instance"
  zone               = "us-central1-a"
  version {
    instance_template = google_compute_instance_template.ha_template.self_link
  }
  target_size        = 2
  auto_healing_policies {
    health_check      = google_compute_health_check.ha_health_check.self_link
    initial_delay_sec = 300
  }
}

resource "google_compute_instance_template" "ha_template" {
  name         = "ha-instance-template"
  machine_type = "e2-medium"
  disk {
    source_image = "projects/debian-cloud/global/images/family/debian-11"
    auto_delete  = true
    boot         = true
  }
  network_interface {
    network = "default"
    access_config {}
  }
}

resource "google_compute_health_check" "ha_health_check" {
  name               = "ha-health-check"
  check_interval_sec = 5
  timeout_sec        = 5
  healthy_threshold  = 2
  unhealthy_threshold = 2
  tcp_health_check {
    port = 80
  }
}

resource "google_compute_region_backend_service" "ha_backend" {
  name                  = "ha-backend-service"
  region                = "us-central1"
  protocol              = "HTTP"
  health_checks         = [google_compute_health_check.ha_health_check.self_link]
  backend {
    group = google_compute_instance_group_manager.ha_instance_group.instance_group
  }
}

resource "google_compute_url_map" "ha_url_map" {
  name            = "ha-url-map"
  default_service = google_compute_region_backend_service.ha_backend.self_link
}

resource "google_compute_target_http_proxy" "ha_http_proxy" {
  name    = "ha-http-proxy"
  url_map = google_compute_url_map.ha_url_map.self_link
}

resource "google_compute_global_forwarding_rule" "ha_forwarding_rule" {
  name       = "ha-forwarding-rule"
  target     = google_compute_target_http_proxy.ha_http_proxy.self_link
  port_range = "80"
}

This Terraform file creates a high availability setup on GCP.

It defines an instance template for VM setup, then an instance group manager to run two VMs for redundancy.

A health check monitors VM health to replace unhealthy ones automatically.

A backend service connects the instance group to a load balancer.

The URL map and HTTP proxy route traffic to the backend.

The global forwarding rule listens on port 80 and sends traffic to the proxy.

Commands
This command initializes Terraform in the current directory. It downloads the Google provider plugin and prepares Terraform to manage resources.
Terminal
terraform init
Expected OutputExpected
Initializing the backend... Initializing provider plugins... - Finding latest version of hashicorp/google... - Installing hashicorp/google v4.0.0... - Installed hashicorp/google v4.0.0 (signed by HashiCorp) Terraform has been successfully initialized! You may now begin working with Terraform. Try running "terraform plan" to see any changes required for your infrastructure.
This command shows what Terraform will create or change in your GCP project based on the configuration file.
Terminal
terraform plan
Expected OutputExpected
An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # google_compute_instance_template.ha_template will be created + resource "google_compute_instance_template" "ha_template" { + id = (known after apply) + name = "ha-instance-template" ... } # google_compute_instance_group_manager.ha_instance_group will be created + resource "google_compute_instance_group_manager" "ha_instance_group" { + id = (known after apply) + name = "ha-instance-group" ... } Plan: 7 to add, 0 to change, 0 to destroy. ───────────────────────────────────────────────────────────────────────────── Note: You didn't specify an "-out" parameter to save this plan, so Terraform can't guarantee that exactly these actions will be performed if "terraform apply" is subsequently run.
This command applies the configuration, creating all resources in GCP automatically without asking for confirmation.
Terminal
terraform apply -auto-approve
Expected OutputExpected
google_compute_instance_template.ha_template: Creating... google_compute_health_check.ha_health_check: Creating... google_compute_instance_template.ha_template: Creation complete after 10s [id=ha-instance-template] google_compute_health_check.ha_health_check: Creation complete after 8s [id=ha-health-check] google_compute_instance_group_manager.ha_instance_group: Creating... google_compute_region_backend_service.ha_backend: Creating... google_compute_instance_group_manager.ha_instance_group: Creation complete after 15s [id=ha-instance-group] google_compute_region_backend_service.ha_backend: Creation complete after 12s [id=ha-backend-service] google_compute_url_map.ha_url_map: Creating... google_compute_target_http_proxy.ha_http_proxy: Creating... google_compute_url_map.ha_url_map: Creation complete after 7s [id=ha-url-map] google_compute_target_http_proxy.ha_http_proxy: Creation complete after 6s [id=ha-http-proxy] google_compute_global_forwarding_rule.ha_forwarding_rule: Creating... google_compute_global_forwarding_rule.ha_forwarding_rule: Creation complete after 5s [id=ha-forwarding-rule] Apply complete! Resources: 7 added, 0 changed, 0 destroyed.
→
-auto-approve - Skip manual approval to apply changes immediately
This command lists forwarding rules in your GCP project to verify the load balancer is set up and listening on port 80.
Terminal
gcloud compute forwarding-rules list
Expected OutputExpected
NAME REGION IP_ADDRESS IP_PROTOCOL PORT_RANGE TARGET ha-forwarding-rule global 34.123.45.67 TCP 80 target-http-proxy/ha-http-proxy
Key Concept

If you remember nothing else from this pattern, remember: spreading your app across multiple servers with health checks and a load balancer keeps it running even if one server fails.

Common Mistakes
Setting target_size to 1 in the instance group manager
Having only one instance means no backup if it fails, so no real high availability.
Set target_size to at least 2 to have multiple instances for redundancy.
Not configuring a health check for the instance group
Without health checks, unhealthy instances won't be detected or replaced automatically.
Always configure a health check and link it to the instance group manager for auto healing.
Forgetting to create a forwarding rule for the load balancer
Without a forwarding rule, traffic won't reach your load balancer and your app won't be accessible.
Create a global forwarding rule that listens on the desired port and points to the HTTP proxy.
Summary
Initialize Terraform to prepare the environment with 'terraform init'.
Use 'terraform plan' to preview the resources Terraform will create.
Apply the configuration with 'terraform apply -auto-approve' to create a high availability setup.
Verify the load balancer forwarding rule with 'gcloud compute forwarding-rules list' to ensure traffic routing.

Practice

(1/5)
1. What is the main purpose of configuring high availability in a cloud service?
easy
A. To make the service run faster for a single user
B. To reduce the cost of running the service
C. To limit the number of users accessing the service
D. To keep the service running even if some parts fail

Solution

  1. Step 1: Understand high availability concept

    High availability means the system stays up and working even if some components fail.

  2. Step 2: Identify the main goal

    The goal is to avoid downtime and keep the service accessible to users.

  3. Final Answer:

    To keep the service running even if some parts fail -> Option D

  4. Quick Check:

    High availability = service stays running despite failures [OK]
Hint: High availability means no downtime during failures [OK]
Common Mistakes:
  • Confusing high availability with cost reduction
  • Thinking it only improves speed for one user
  • Assuming it limits user access
2. Which GCP resource helps automatically replace unhealthy VM instances to maintain high availability?
easy
A. Managed Instance Group with health checks
B. Cloud Storage Bucket
C. Cloud SQL instance
D. Cloud Functions

Solution

  1. Step 1: Identify resource for auto healing

    Managed Instance Groups (MIGs) can use health checks to detect unhealthy VMs.

  2. Step 2: Understand auto replacement

    MIGs automatically recreate unhealthy instances to keep the service healthy.

  3. Final Answer:

    Managed Instance Group with health checks -> Option A

  4. Quick Check:

    Auto replace unhealthy VMs = Managed Instance Group + health checks [OK]
Hint: Auto healing uses Managed Instance Groups with health checks [OK]
Common Mistakes:
  • Choosing storage or database services instead of compute
  • Confusing Cloud Functions with VM management
  • Ignoring health checks role
3. Consider a Managed Instance Group spread across two zones with health checks enabled. If one zone fails completely, what happens to the instances?
medium
A. Instances in the failed zone are replaced in the same zone
B. Instances in the failed zone remain down until manual restart
C. Instances in the failed zone are replaced in the other zone
D. All instances in both zones are shut down

Solution

  1. Step 1: Understand multi-zone MIG behavior

    MIGs spread instances across zones for fault tolerance.

  2. Step 2: Analyze failure impact

    If one zone fails, MIG recreates instances in healthy zones to maintain capacity.

  3. Final Answer:

    Instances in the failed zone are replaced in the other zone -> Option C

  4. Quick Check:

    Zone failure triggers instance replacement in healthy zones [OK]
Hint: MIGs replace failed zone instances in other zones automatically [OK]
Common Mistakes:
  • Thinking instances are replaced in the failed zone
  • Assuming manual restart is needed
  • Believing all instances shut down
4. You configured a Managed Instance Group with health checks, but unhealthy instances are not being replaced. What is the most likely cause?
medium
A. Autohealing is disabled in the instance group
B. Instances are in multiple zones
C. Health check is not attached to the instance group
D. Firewall rules block all traffic

Solution

  1. Step 1: Check health check attachment

    Health checks must be attached to trigger autohealing, but this alone is not enough.

  2. Step 2: Verify autohealing setting

    Autohealing must be enabled in the instance group to replace unhealthy instances.

  3. Final Answer:

    Autohealing is disabled in the instance group -> Option A

  4. Quick Check:

    Autohealing disabled = no instance replacement [OK]
Hint: Autohealing must be enabled to replace unhealthy instances [OK]
Common Mistakes:
  • Assuming health check attachment alone triggers replacement
  • Blaming multi-zone setup
  • Ignoring autohealing configuration
5. You want to design a highly available web application on GCP that remains online even if an entire zone fails. Which combination of configurations best achieves this?
hard
A. Single-zone Managed Instance Group with health checks and autoscaling
B. Multi-zone Managed Instance Group with health checks and autoscaling
C. Single VM instance with a static IP and firewall rules
D. Cloud Storage bucket with versioning enabled

Solution

  1. Step 1: Understand zone failure impact

    A single zone failure can take down all instances in that zone if only single-zone is used.

  2. Step 2: Choose multi-zone MIG with health checks and autoscaling

    This setup spreads instances across zones, replaces unhealthy ones, and adjusts capacity automatically.

  3. Step 3: Evaluate other options

    Single-zone lacks zone failure protection; single VM is a single point of failure; storage bucket is not compute.

  4. Final Answer:

    Multi-zone Managed Instance Group with health checks and autoscaling -> Option B

  5. Quick Check:

    Multi-zone MIG + health checks + autoscaling = high availability [OK]
Hint: Use multi-zone MIG with health checks and autoscaling for best availability [OK]
Common Mistakes:
  • Choosing single-zone MIG ignoring zone failure
  • Using single VM which is a single failure point
  • Confusing storage bucket with compute resources
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard