Atelier pratique — ACE Google Cloud Associate Cloud Engineer

Présentation

Prérequis

Étapes

1. 1.Fournisseur, services de projet, dénomination

   Activez les API Compute Engine, IAM et Cloud Logging. L'examen ACE teste ce modèle d'activation d'API par ressource à plusieurs reprises.

   Copier

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       google = { source = "hashicorp/google", version = "~> 6.0" }
     }
   }
   
   provider "google" {
     project = "your-project-id" # REPLACE
     region  = "us-central1"
     zone    = "us-central1-a"
   }
   
   locals {
     labels = {
       project    = "certlabpro-ace"
       managed_by = "terraform"
     }
   }
   
   resource "google_project_service" "compute" {
     service            = "compute.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "iam" {
     service            = "iam.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "logging" {
     service            = "logging.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "monitoring" {
     service            = "monitoring.googleapis.com"
     disable_on_destroy = false
   }

2. 2.Créer un VPC personnalisé + sous-réseau régional

   Déploie :

   • VPC
   • Compute Engine

   Les réseaux GCP sont globaux — un seul VPC s'étend sur toutes les régions, et les sous-réseaux sont des primitives régionales qui en sont extraites. C'est un type de question récurrent à l'examen ACE : AWS a des VPC régionaux ; Azure a des VNets régionales ; GCP a un VPC global avec des sous-réseaux régionaux.

   Nous désactivons auto_create_subnetworks (VPC en mode personnalisé, la valeur par défaut recommandée par ACE) et créons un seul sous-réseau /24 dans us-central1 avec l'Accès Google privé activé afin que les VM sans IP externes puissent toujours atteindre les API GCP.

   Copier

   resource "google_compute_network" "main" {
     name                    = "certlabpro-ace-vpc"
     auto_create_subnetworks = false
     routing_mode            = "REGIONAL"
   
     depends_on = [google_project_service.compute]
   }
   
   resource "google_compute_subnetwork" "main" {
     name                     = "certlabpro-ace-subnet"
     ip_cidr_range            = "10.10.1.0/24"
     region                   = "us-central1"
     network                  = google_compute_network.main.id
     private_ip_google_access = true
   }

3. 3.Ajouter deux règles de pare-feu (interne + IAP SSH)

   Déploie :

   • VPC

   Les règles de pare-feu GCP sont limitées au VPC (non par sous-réseau) et ont une direction explicite : trafic entrant (par défaut) ou sortant. Le trafic entrant par défaut est en refus total ; le trafic sortant par défaut est en autorisation totale. L'examen ACE teste sans relâche cet invariant direction + refus par défaut.

   Nous ajoutons :

   1. Autoriser l'interne — TCP/UDP/ICMP entre les VM du sous-réseau 10.10.1.0/24.
   2. Autoriser IAP SSH — TCP/22 depuis la plage de passerelle IAP de Google (35.235.240.0/20) afin que vous puissiez vous connecter en SSH sans exposer la VM à Internet.

   La règle IAP-SSH est le modèle recommandé par ACE — elle nécessite roles/iap.tunnelResourceAccessor sur la VM (la liaison est gérée à l'étape 4).

   Copier

   resource "google_compute_firewall" "allow_internal" {
     name      = "certlabpro-ace-allow-internal"
     network   = google_compute_network.main.name
     direction = "INGRESS"
   
     source_ranges = ["10.10.1.0/24"]
   
     allow {
       protocol = "tcp"
     }
     allow {
       protocol = "udp"
     }
     allow {
       protocol = "icmp"
     }
   }
   
   resource "google_compute_firewall" "allow_iap_ssh" {
     name      = "certlabpro-ace-allow-iap-ssh"
     network   = google_compute_network.main.name
     direction = "INGRESS"
   
     source_ranges = ["35.235.240.0/20"] # IAP gateway range
   
     allow {
       protocol = "tcp"
       ports    = ["22"]
     }
   }

4. 4.Provisionner une VM GCE avec un compte de service à moindre privilège

   Déploie :

   • Compute Engine
   • IAM

   Les VM Compute Engine s'exécutent avec un compte de service attaché — l'équivalent GCP d'un profil d'instance AWS EC2 ou d'une identité gérée de VM Azure. Modèle recommandé par ACE : ne jamais utiliser le compte de service Compute par défaut (privilèges excessifs) ; toujours créer un compte de service par charge de travail avec uniquement les rôles IAM dont la charge de travail a besoin.

   Nous créons un compte de service, lui accordons les rôles roles/logging.logWriter + roles/monitoring.metricWriter (le minimum pour que l'Ops Agent envoie des journaux/métriques), et l'attachons à une VM Debian e2-micro sans IP externe. La règle de pare-feu IAP-SSH de l'étape 3 vous permet d'y accéder via un tunnel.

   Copier

   resource "google_service_account" "vm" {
     account_id   = "certlabpro-ace-vm-sa"
     display_name = "ACE lab VM service account"
   }
   
   resource "google_project_iam_member" "vm_log_writer" {
     project = data.google_project.current.project_id
     role    = "roles/logging.logWriter"
     member  = "serviceAccount:${google_service_account.vm.email}"
   }
   
   resource "google_project_iam_member" "vm_metric_writer" {
     project = data.google_project.current.project_id
     role    = "roles/monitoring.metricWriter"
     member  = "serviceAccount:${google_service_account.vm.email}"
   }
   
   data "google_project" "current" {}
   
   resource "google_compute_instance" "vm" {
     name         = "certlabpro-ace-vm"
     machine_type = "e2-micro"
     zone         = "us-central1-a"
   
     boot_disk {
       initialize_params {
         image = "debian-cloud/debian-12"
       }
     }
   
     network_interface {
       subnetwork = google_compute_subnetwork.main.id
       # No access_config block = no external IP. SSH via IAP only.
     }
   
     service_account {
       email  = google_service_account.vm.email
       scopes = ["cloud-platform"] # API scope; IAM does the real gating
     }
   
     labels = local.labels
   }

5. 5.Câbler une métrique Cloud Logging + une politique d'alerte

   Déploie :

   • Cloud Logging
   • Cloud Monitoring

   Forme d'observabilité recommandée par ACE : une métrique basée sur les journaux compte les correspondances d'un filtre Cloud Logging, puis une politique d'alerte Cloud Monitoring se déclenche lorsque la métrique dépasse un seuil. Nous surveillons les lignes de journal severity >= ERROR de toute VM GCE dans ce projet, les comptons par minute, et alertons lorsque plus de 5 se produisent dans une fenêtre de 5 minutes.

   Le canal de notification est laissé implicite — les politiques d'alerte nécessitent un tableau notification_channels, mais le canal lui-même (e-mail, Slack, PagerDuty) est généralement configuré une fois par projet dans la console. L'examen ACE teste ce triangle métrique de journal → politique d'alerte → canal de notification comme primitive d'observabilité standard.

   Copier

   resource "google_logging_metric" "vm_errors" {
     name   = "certlabpro_ace_vm_errors"
     filter = "resource.type=\"gce_instance\" AND severity >= ERROR"
   
     metric_descriptor {
       metric_kind = "DELTA"
       value_type  = "INT64"
     }
   
     depends_on = [google_project_service.logging]
   }
   
   resource "google_monitoring_alert_policy" "vm_error_burst" {
     display_name = "ACE lab — VM error burst"
     combiner     = "OR"
   
     conditions {
       display_name = "More than 5 ERROR lines per 5 minutes"
   
       condition_threshold {
         filter          = "metric.type=\"logging.googleapis.com/user/${google_logging_metric.vm_errors.name}\" AND resource.type=\"gce_instance\""
         duration        = "300s"
         comparison      = "COMPARISON_GT"
         threshold_value = 5
   
         aggregations {
           alignment_period   = "60s"
           per_series_aligner = "ALIGN_DELTA"
         }
       }
     }
   
     # notification_channels = [] # add channels via the console or as a separate TF resource
   
     depends_on = [google_project_service.monitoring]
   }

Nettoyage