Google ACE: Déploiement, configuration et automatisation — Guide d'étude

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Fait partie du Google Associate Cloud Engineer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Opérations en ligne de commande et gestion de l’environnement

Configurations de Cloud Shell et gcloud :

• Cloud Shell fournit un environnement d’administration géré avec gcloud pré-authentifié et un répertoire personnel persistant.
• Utilisez des configurations nommées pour changer rapidement de compte, de projet et de région : gcloud config configurations create prod gcloud config set project my-prod gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-a gcloud config configurations activate prod
• Inspectez la configuration active avec gcloud config list. Pour GKE, obtenez les informations d’identification : gcloud container clusters get-credentials my-cluster –region us-central1

Modèles de commandes Compute :

• Créer une VM avec une adresse IP interne réservée : gcloud compute addresses create license-ip –region=us-central1 –subnet=default –addresses=10.0.3.21 gcloud compute instances create license-server –zone=us-central1-a –subnet=default –private-network-ip=10.0.3.21 –tags=license
• Créer un VPC personnalisé, un sous-réseau et une règle de pare-feu : gcloud compute networks create core –subnet-mode=custom gcloud compute networks subnets create core-us –network=core –range=10.0.0.0/20 –region=us-central1 gcloud compute firewall-rules create allow-https –network=core –allow=tcp:443 –target-tags=web

Modèles IAM :

• Accorder un rôle au niveau du projet : gcloud projects add-iam-policy-binding my-project –member=group:ops@example.com –role=roles/logging.viewer
• Copier des rôles personnalisés entre les projets : gcloud iam roles copy myCustomRole –source=my-dev –destination=my-prod

Modèles de stockage :

• Créer un bucket et y importer des objets : gcloud storage buckets create gs://backups-prod –location=us-central1 –class=coldline –uniform-bucket-level-access gcloud storage cp ./backup.tar.gz gs://backups-prod/
• Configurer le cycle de vie via un fichier et l’appliquer avec gcloud storage buckets update –lifecycle-file=policy.json

Activation et vérification des API :

• Activer Pub/Sub pour une application : gcloud services enable pubsub.googleapis.com
• Lister les services activés : gcloud services list –enabled

Gouvernance, dérive et automatisation

Dérive de configuration et application des règles :

• Détectez la dérive en exécutant terraform plan à intervalles réguliers ; faites échouer les builds en cas de changements inattendus.
• Appliquez les contraintes des règles d’organisation (par ex., restreindre les adresses IP externes) et validez les configurations des ressources avec la politique sous forme de code (policy-as-code) avant l’application.
• Pour Kubernetes, utilisez Config Sync et Policy Controller pour réconcilier en continu et bloquer les changements non conformes.
• Auditabilité : fiez-vous aux journaux d’activité d’administration (Admin Activity) et d’accès aux données (Data Access) ; acheminez-les vers BigQuery pour analyse. Utilisez Cloud Asset Inventory pour des requêtes sur l’état à un instant T et dans le temps.

Quotas et limites :

• Inspectez les quotas par région et par projet ; prévoyez une marge de manœuvre pour l’autoscaling et les déploiements :

undefined

• Demandez des augmentations avant une croissance planifiée ou des déploiements à grande échelle.

Tâches opérationnelles automatisées :

• Cloud Scheduler déclenche des points de terminaison HTTP, des sujets Pub/Sub ou des Workflows selon une planification cron. Assurez-vous que les gestionnaires sont idempotents ; configurez les tentatives et les sujets de lettres mortes (dead-letter topics).
• Workflows orchestre l’automatisation multi-étapes à travers les API Google avec des tentatives, des étapes parallèles et une logique de compensation.
• Les jobs Cloud Run exécutent des tâches batch ou administratives conteneurisées à la demande ou via Scheduler. Préférez les jobs pour les charges de travail uniques ou itératives ; utilisez les permissions minimales sur le compte de service du job.

Sécurité et observabilité des déploiements :

• Intégrez des vérifications de santé (health checks) et des sondes de disponibilité (readiness probes) dans les services. Pour les MIG dont le démarrage est lent, augmentez le délai initial pour éviter les actions de scaling prématurées.
• Collectez les métriques de déploiement et les budgets d’erreurs ; mettez en pause ou annulez automatiquement les déploiements lorsque les SLO se dégradent.

Scénario de problème pratique

Altostrat Media doit standardiser les déploiements multi-environnements pour un service basé sur GKE tout en éliminant la dérive de configuration et en garantissant un retour en arrière (rollback) rapide. Ils doivent également réserver une adresse IP interne fixe pour un serveur de licences hérité sans reconfigurer l’application.

1. Créer des modules Terraform fondamentaux et un état distant

• Implémentez des modules pour le VPC, les sous-réseaux, GKE, les comptes de service et les règles de pare-feu. Configurez un backend Cloud Storage avec le versioning et une politique de rétention pour le bucket d’état.
• Justification : La modularisation favorise la réutilisation et la cohérence ; un état distant et versionné permet la collaboration, la récupérabilité et le verrouillage.

2. Activer les services requis et établir des identités d’automatisation à moindre privilège

• Activez compute.googleapis.com, container.googleapis.com, clouddeploy.googleapis.com, artifactregistry.googleapis.com.
• Créez des comptes de service par environnement pour Terraform, Cloud Build et Cloud Deploy ; accordez des rôles minimaux (par ex., roles/container.admin aux déployeurs, pas aux builders).
• Justification : L’activation préalable et la définition de la portée des rôles réduisent les échecs de déploiement et limitent le rayon d’impact (blast radius).

3. Provisionner le réseau et réserver l’adresse IP héritée

• Avec Terraform, créez un VPC personnalisé, des sous-réseaux régionaux et des règles de pare-feu basées sur des tags réseau.
• Réservez l’adresse IP interne :

undefined

• Justification : Le réseau déclaratif garantit la répétabilité ; la réservation de l’adresse IP préserve les hypothèses de l’application.

4. Compiler les artefacts avec Cloud Build et les publier sur Artifact Registry

• Définissez un fichier cloudbuild.yaml pour exécuter les tests, compiler le conteneur, l’analyser et pousser un digest immuable vers Artifact Registry.
• Justification : Les artefacts immuables et analysés sont la base de promotions sûres et de la traçabilité (provenance).

5. Configurer le pipeline Cloud Deploy avec des cibles dev → qa → prod

• Définissez un pipeline de livraison et des cibles ; référencez la configuration Skaffold pour générer les manifestes. Exigez une approbation manuelle pour la prod et configurez des vérifications.
• Justification : La promotion structurée impose des contrôles ; les politiques par cible évitent les déploiements accidentels en prod.

6. Déployer les mises à jour GKE avec une stratégie canary et des portes de validation de santé (health gates)

• Utilisez une politique de déploiement canary pour basculer 10 %, puis 50 %, puis 100 % du trafic, sous réserve de vérifications du SLO et du taux d’erreur.
• Justification : La livraison progressive réduit les risques et fournit des points de retour en arrière naturels.

7. Éliminer la dérive avec des plans planifiés et des vérifications de règles

• Un job nocturne exécute terraform plan et un validateur de politique sous forme de code ; il alerte en cas de différences ou de violations inattendues.
• Justification : La détection précoce empêche la dérive de s’accumuler et de casser les futures applications (apply).

8. Opérationnaliser la VM du serveur de licences avec l’adresse IP réservée

• Créez la VM liée à l’adresse réservée et avec les bons tags :

undefined

• Justification : Garantit l’accessibilité sans modifier l’application ; les tags maintiennent la portée des règles de pare-feu restreinte.

9. Automatiser les tâches récurrentes avec Scheduler, Workflows et les jobs

• Cloud Scheduler déclenche un Workflow pour effectuer la rotation des clés de compte de service lorsque c’est inévitable et pour lancer un job Cloud Run pour les tâches hebdomadaires de nettoyage de la base de données (vacuum).
• Justification : La planification centralisée associée à l’orchestration apporte fiabilité et observabilité avec des tentatives et une logique de compensation.

10. Planifier les retours en arrière et valider les seuils de disponibilité

• Définissez des playbooks de retour en arrière pour re-promouvoir la dernière bonne version. Ajustez les sondes de disponibilité (readiness probes) et, pour toute charge de travail basée sur des MIG, augmentez les délais initiaux des vérifications de santé pour correspondre au temps de chauffe de l’application.
• Justification : Un retour en arrière pré-planifié et des vérifications de santé ajustées préviennent les défaillances en cascade et le surprovisionnement lors d’incidents.

Cette approche aligne les artefacts immuables, l’infrastructure déclarative, les promotions contrôlées (gated promotions) et l’automatisation à moindre privilège pour fournir des opérations sûres, auditables et répétables sur Google Cloud.

← Stockage · Tous les domaines · Surveillance →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Google →