High availability configuration in GCP - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create a managed instance group with autohealing enabled.

GCP

resource "google_compute_instance_group_manager" "example" {
  name               = "example-group"
  base_instance_name  = "example-instance"
  zone               = "us-central1-a"
  version {
    instance_template = google_compute_instance_template.example.self_link
  }
  auto_healing_policies {
    health_check      = [1]
    initial_delay_sec = 300
  }
}

Drag options to blanks, or click blank then click option'

Agoogle_compute_subnetwork.example.self_link

Bgoogle_compute_health_check.example.self_link

Cgoogle_compute_network.example.self_link

Dgoogle_compute_firewall.example.self_link

Attempts:

3 left

💡 Hint

Common Mistakes

Using a firewall or network resource instead of a health check.

Omitting the health check reference.

The auto_healing_policies block requires a health check resource link to monitor instance health and enable autohealing.

2fill in blank

medium

Complete the code to configure a global HTTP load balancer backend service with session affinity.

GCP

resource "google_compute_backend_service" "default" {
  name                  = "backend-service"
  protocol              = "HTTP"
  load_balancing_scheme = "EXTERNAL"
  session_affinity      = [1]
  backends {
    group = google_compute_instance_group.example.self_link
  }
  health_checks = [google_compute_health_check.default.self_link]
}

Drag options to blanks, or click blank then click option'

ANONE

BCLIENT_IP

CGENERATED_COOKIE

DHTTP_COOKIE

Attempts:

3 left

💡 Hint

Common Mistakes

Using NONE disables session affinity.

CLIENT_IP may not work well with clients behind proxies.

Setting session_affinity to GENERATED_COOKIE enables the load balancer to route requests from the same client to the same backend using a generated cookie.

3fill in blank

hard

Fix the error in the health check configuration to enable HTTPS health checks.

GCP

resource "google_compute_health_check" "https_check" {
  name               = "https-health-check"
  https_health_check {
    port             = [1]
    request_path     = "/healthz"
  }
  check_interval_sec = 10
  timeout_sec        = 5
  healthy_threshold  = 3
  unhealthy_threshold = 3
}

Drag options to blanks, or click blank then click option'

A443

B80

C8080

D22

Attempts:

3 left

💡 Hint

Common Mistakes

Using port 80 for HTTPS health checks.

Using non-standard ports without proper configuration.

HTTPS health checks must use port 443, the standard HTTPS port, to properly check the service.

4fill in blank

hard

Fill both blanks to configure an instance group with autoscaling based on CPU utilization.

GCP

resource "google_compute_autoscaler" "cpu_autoscaler" {
  name   = "cpu-autoscaler"
  target = google_compute_instance_group_manager.example.self_link
  autoscaling_policy {
    max_replicas    = [1]
    cpu_utilization {
      target = [2]
    }
  }
}

Drag options to blanks, or click blank then click option'

A5

B0.6

C10

D0.8

Attempts:

3 left

💡 Hint

Common Mistakes

Setting max_replicas too high or too low.

Using CPU utilization target outside 0-1 range.

The max_replicas sets the maximum number of instances to 5, and cpu_utilization.target is set to 0.6 (60%) to trigger scaling.

5fill in blank

hard

Fill all three blanks to configure a global forwarding rule for HTTPS traffic with a target proxy and SSL certificate.

GCP

resource "google_compute_global_forwarding_rule" "https_forwarding_rule" {
  name       = "https-forwarding-rule"
  target     = [1]
  port_range = [2]
  ip_protocol = [3]
}

Drag options to blanks, or click blank then click option'

Agoogle_compute_target_https_proxy.https_proxy.self_link

B"443"

C"TCP"

Dgoogle_compute_target_http_proxy.http_proxy.self_link

Attempts:

3 left

💡 Hint

Common Mistakes

Using HTTP proxy instead of HTTPS proxy as target.

Using wrong port or protocol for HTTPS traffic.

The forwarding rule targets the HTTPS proxy resource, listens on port 443, and uses TCP as the IP protocol for HTTPS traffic.

Practice

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