Guide

Centraliser la facturation et l'application des politiques tout en accordant aux unités commerciales une autonomie administrative.

→Utiliser un nœud d'Organisation avec des Dossiers pour chaque unité commerciale. Créer des projets dans les dossiers. Lier tous les projets à un seul Compte de facturation.

Pourquoi: Les Dossiers fournissent des limites administratives et l'héritage des politiques. Un compte de facturation unique centralise la gestion des coûts et permet des remises à l'échelle de l'organisation.

Référence↗

Informer les finances lorsque les dépenses d'un projet atteignent certains pourcentages d'un budget.

→Dans Cloud Billing, créer un Budget pour le projet. Définir plusieurs règles de seuil d'alerte (par exemple, 50%, 90%, 100%) qui envoient des notifications à un sujet Pub/Sub ou par e-mail.

Pourquoi: Les Budgets sont destinés aux alertes, et non à l'arrêt des dépenses. Pour plafonner automatiquement les dépenses, une notification Pub/Sub doit déclencher une fonction Cloud Functions pour désactiver la facturation ou arrêter les ressources.

Référence↗

Analyser les coûts cloud granulaires au niveau des ressources et suivre les dépenses par centre de coûts.

→Activer l'exportation détaillée de la facturation vers un ensemble de données BigQuery. Appliquer des étiquettes (par exemple, `cost-center: "finance"`) aux ressources. Interroger la table BigQuery et regrouper par étiquettes pour l'analyse.

Pourquoi: L'exportation de la facturation vers BigQuery fournit les données de coût les plus détaillées, y compris les étiquettes, ce qui est essentiel pour les modèles de refacturation et de rétrofacturation personnalisés.

Référence↗

Appliquer des normes de sécurité et de configuration à tous les projets d'une organisation (par exemple, restreindre les emplacements des ressources, exiger un accès uniforme aux buckets, désactiver les IP publiques).

→Appliquer des contraintes de Politique d'organisation au niveau de l'Organisation ou du Dossier. Exemples : `gcp.resourceLocations` pour la résidence des données, `storage.uniformBucketLevelAccess` pour la sécurité GCS, `compute.vmExternalIpAccess` pour empêcher les IP publiques.

Pourquoi: Les politiques d'organisation sont héritées et fournissent un contrôle préventif, bloquant les actions non conformes avant qu'elles ne se produisent. C'est plus efficace que l'audit réactif.

Référence↗

Empêcher la suppression accidentelle d'un projet de production critique.

→Placer un privilège (lien) sur le projet à l'aide de `gcloud alpha resource-manager liens create`.

Pourquoi: Un privilège (lien) est une propriété qui bloque la suppression d'un projet. Il doit être explicitement supprimé par un utilisateur ayant le rôle `resourcemanager.lienModifier` avant que le projet ne puisse être supprimé.

Basculer efficacement entre différents projets et comptes utilisateurs lors de l'utilisation de la CLI gcloud.

→Utiliser `gcloud config configurations create` pour créer des configurations nommées pour chaque projet/compte. Basculer entre elles à l'aide de `gcloud config configurations activate [CONFIG_NAME]`.

Pourquoi: Les configurations stockent des paramètres tels que le projet, le compte, la région et la zone, évitant ainsi de devoir les spécifier à chaque commande.

Exécuter un microservice HTTP conteneurisé, sans état, avec un trafic variable, en minimisant la charge opérationnelle et les coûts.

→Déployer le conteneur sur Cloud Run.

Pourquoi: Cloud Run est entièrement géré, se met à l'échelle à zéro (éliminant les coûts pour les périodes d'inactivité) et s'adapte automatiquement en fonction des requêtes entrantes. Il est idéal pour les services web sans état.

Référence↗

Exécuter une tâche de traitement par lots tolérante aux pannes et flexible en termes de temps au coût le plus bas possible.

→Utiliser des VM Spot (anciennement VM préemptibles) dans un groupe d'instances gérées.

Pourquoi: Les VM Spot offrent jusqu'à 91% de réduction par rapport aux prix à la demande. Elles conviennent aux charges de travail qui peuvent être arrêtées et redémarrées, comme de nombreuses tâches de traitement par lots.

Déployer une application web qui nécessite une haute disponibilité (par exemple, 99,9%) et une mise à l'échelle automatique.

→Utiliser un groupe d'instances gérées (MIG) régional avec une politique de mise à l'échelle automatique, déployé derrière un équilibreur de charge HTTP(S) externe global.

Pourquoi: Un MIG régional distribue automatiquement les instances sur plusieurs zones pour la tolérance aux pannes. L'autoscaling ajuste la capacité pour répondre à la demande, et l'équilibreur de charge fournit un point d'entrée unique.

Stocker des données fréquemment accédées pendant 30 jours, puis rarement pendant un an, puis archivées.

→Stocker dans un bucket Cloud Storage de classe Standard. Créer une règle de cycle de vie pour faire passer les objets en Nearline/Coldline après 30 jours et en Archive après 365 jours.

Pourquoi: Les règles de cycle de vie automatisent l'optimisation des coûts en déplaçant les données vers des classes de stockage moins chères en fonction de l'âge ou d'autres conditions, sans intervention manuelle.

Référence↗

Une application distribuée mondialement nécessite une base de données relationnelle avec une évolutivité horizontale et une forte cohérence.

→Utiliser Cloud Spanner.

Pourquoi: Cloud Spanner est le seul service qui fournit une base de données relationnelle distribuée mondialement, fortement cohérente et prenant en charge SQL. Cloud SQL est régional.

Une application nécessite une base de données PostgreSQL ou MySQL gérée avec un SLA de disponibilité de 99,95% et un basculement automatique.

→Utiliser Cloud SQL avec la configuration de haute disponibilité (HA) activée.

Pourquoi: La configuration HA crée une instance principale et une instance de secours dans une zone différente. Les données sont répliquées de manière synchrone et le basculement est automatique.

Concevoir un VPC pour une application à 3 niveaux (web, application, base de données) où le niveau de la base de données ne doit pas être accessible depuis Internet.

→Créer un VPC en mode personnalisé avec un sous-réseau séparé pour chaque niveau. Provisionner les instances de base de données avec uniquement des adresses IP privées dans leur sous-réseau dédié.

Pourquoi: L'isolation des niveaux dans des sous-réseaux séparés permet des règles de pare-feu granulaires. L'omission des adresses IP externes sur les instances de base de données est le moyen le plus direct d'empêcher l'accès à Internet.

Déployer une application avec état (par exemple, une base de données) sur GKE qui nécessite des identifiants réseau stables et un stockage persistant.

→Utiliser un StatefulSet avec un modèle PersistentVolumeClaim.

Pourquoi: Les StatefulSets sont conçus pour les charges de travail avec état, fournissant des noms d'hôte stables (par exemple, `pod-0`, `pod-1`) et provisionnant automatiquement un PersistentVolume unique pour chaque réplique.

Un service Cloud Run sensible à la latence doit éviter les démarrages à froid (cold starts) lors des pics de trafic.

→Déployer le service avec le drapeau `--min-instances` défini à 1 ou plus.

Pourquoi: Définir un nombre minimal d'instances maintient un nombre spécifié de conteneurs "chauds" et prêts à servir les requêtes, éliminant ainsi la latence associée au démarrage d'un nouveau conteneur.

Exécuter une fonction sans serveur automatiquement chaque fois qu'un nouveau fichier est téléchargé vers un bucket Cloud Storage.

→Déployer une Cloud Function (2e génération) avec un déclencheur Eventarc pour l'événement `google.cloud.storage.object.v1.finalized` sur le bucket spécifié.

Pourquoi: Eventarc fournit une architecture unifiée basée sur les événements. Le déclencheur GCS est le moyen standard et géré de connecter les événements de stockage au calcul sans serveur sans interrogation.

Déployer une nouvelle version d'une application App Engine pour les tests sans y envoyer immédiatement le trafic de production.

→Déployer la nouvelle version à l'aide de `gcloud app deploy --no-promote`.

Pourquoi: Le drapeau `--no-promote` crée la nouvelle version mais n'y déplace aucun trafic. Vous pouvez ensuite la tester en utilisant son URL spécifique à la version et migrer le trafic manuellement lorsque vous êtes prêt.

Créer un équilibreur de charge HTTP(S) global pour une application web s'exécutant sur des instances Compute Engine.

→Créer ces composants dans l'ordre : Groupe d'instances (avec des VM), Vérification de l'état (Health Check), Service de backend (pointant vers IG et HC), Carte d'URL (URL Map), Proxy cible HTTP(S) (Target HTTP(S) Proxy), et une Règle de transfert globale (avec une IP publique).

Pourquoi: Cette séquence construit correctement l'équilibreur de charge du backend (instances) au frontend (règle de transfert). Chaque composant a un but spécifique dans le routage et la vérification de l'état.

Une équipe doit gérer l'état Terraform de manière collaborative, en assurant la sécurité et en empêchant les modifications concurrentes.

→Utiliser un bucket Cloud Storage comme backend Terraform. Activer le versionnement des objets pour l'historique et la récupération. Le verrouillage de l'état est géré automatiquement par le backend GCS.

Pourquoi: Un backend GCS distant est la norme pour la collaboration en équipe sur GCP. Il fournit un verrouillage pour éviter la corruption de l'état et le versionnement pour les capacités de restauration.

Recevoir une notification lorsque l'utilisation du CPU sur une VM d'un groupe dépasse 80% pendant une période soutenue (par exemple, 5 minutes).

→Dans Cloud Monitoring, créer une Politique d'alerte. Définir la condition sur `Métrique : utilisation du CPU > 80%` pour `Durée : 5 minutes`. Configurer un canal de notification (par exemple, e-mail, PagerDuty).

Pourquoi: Cloud Monitoring est le service natif pour la création d'alertes basées sur des métriques. La condition de durée est cruciale pour éviter les alertes "flottantes" dues à des pics d'utilisation brefs et normaux.

Conserver des journaux d'audit spécifiques pendant 7 ans pour la conformité, tout en gardant les autres journaux pendant 30 jours.

→Créer un récepteur de journaux (log sink) avec un filtre pour les journaux d'audit. Configurer le récepteur pour exporter vers un bucket Cloud Storage. Appliquer une politique de rétention de 7 ans sur le bucket.

Pourquoi: Cloud Logging a une période de rétention limitée (max 400 jours pour l'activité d'administration). Les récepteurs sont le mécanisme permettant d'acheminer les journaux vers un stockage à long terme moins cher comme GCS ou pour l'analyse dans BigQuery.

Un pod GKE est dans un état `CrashLoopBackOff`. Vous devez visualiser les journaux du conteneur juste avant qu'il ne plante.

→Utiliser la commande `kubectl logs [POD_NAME] --previous`.

Pourquoi: Lorsqu'un conteneur plante et redémarre, `kubectl logs` affiche les journaux du *nouveau* conteneur. Le drapeau `--previous` est essentiel pour visualiser les journaux de l'instance terminée afin de diagnostiquer le plantage.

Un groupe d'instances gérées doit remplacer automatiquement les instances qui deviennent insensibles.

→Configurer une vérification de l'état (par exemple, HTTP, TCP) et l'appliquer à la politique d'auto-réparation du groupe d'instances gérées.

Pourquoi: Le MIG sonde périodiquement les instances en fonction de la vérification de l'état. Si une instance échoue à des vérifications consécutives, le MIG la supprime et la recrée automatiquement à partir du modèle, assurant ainsi la disponibilité de l'application.

Un événement de corruption de données s'est produit dans une base de données Cloud SQL. Vous devez restaurer la base de données à l'état dans lequel elle se trouvait 5 minutes avant l'événement.

→S'assurer que la récupération à un instant précis (PITR) est activée sur l'instance au préalable. Effectuer une opération de restauration, en spécifiant l'horodatage exact à restaurer.

Pourquoi: Le PITR repose sur l'activation de la journalisation binaire. Il permet une récupération granulaire à tout moment dans la fenêtre de rétention, ce qui est essentiel pour minimiser la perte de données (RPO faible).

Automatiser les sauvegardes quotidiennes d'un disque persistant Compute Engine et les conserver pendant 14 jours.

→Créer une politique de ressources pour les instantanés de disque. Configurer un calendrier quotidien et une politique de rétention de 14 jours. Attacher cette politique au disque persistant cible.

Pourquoi: Les planifications d'instantanés sont le moyen géré et "sans souci" d'automatiser les sauvegardes GCE. C'est plus fiable et maintenable que d'utiliser des tâches cron ou des scripts personnalisés.

Une instance Compute Engine doit lire à partir d'un bucket Cloud Storage et écrire dans une table BigQuery. Accorder les autorisations minimales requises.

→Créer un compte de service personnalisé. Lui accorder les rôles `roles/storage.objectViewer` et `roles/bigquery.dataEditor`. Attacher ce compte de service à l'instance.

Pourquoi: L'utilisation d'un compte de service personnalisé avec des rôles spécifiques et prédéfinis évite la nature excessivement permissive du compte de service Compute Engine par défaut, en adhérant au principe du moindre privilège.

Accorder à un utilisateur des autorisations pour gérer les instances GCE mais pas pour les supprimer.

→Créer un rôle IAM personnalisé. Commencer avec les autorisations du rôle `roles/compute.instanceAdmin.v1` et supprimer l'autorisation `compute.instances.delete`.

Pourquoi: Les rôles personnalisés offrent la flexibilité d'accorder un ensemble précis d'autorisations lorsque les rôles prédéfinis sont trop larges ou trop restrictifs pour une fonction de travail spécifique.

Un développeur doit se connecter en SSH à une instance Compute Engine qui n'a pas d'adresse IP externe, conformément à la politique de sécurité.

→Accorder au développeur le rôle `roles/iap.tunnelResourceAccessor`. Il peut ensuite se connecter à l'aide de `gcloud compute ssh [INSTANCE_NAME] --tunnel-through-iap`.

Pourquoi: Le transfert TCP d'Identity-Aware Proxy (IAP) fournit une méthode sécurisée basée sur l'identité pour accéder aux instances internes sans hôtes bastion, VPN ou adresses IP publiques.

Référence↗

Autoriser le trafic SSH entrant (port 22) vers des VM spécifiques uniquement depuis la plage d'adresses IP du bureau de l'entreprise.

→Créer une règle de pare-feu VPC avec `direction: INGRESS`, `action: ALLOW`, `protocol/ports: tcp:22`, `source ranges: [CORPORATE_IP_CIDR]`, et `target tags: [par exemple, "allow-ssh"]`. Appliquer le tag aux VM cibles.

Pourquoi: La combinaison des plages sources et des tags cibles offre un moyen précis et évolutif de contrôler le trafic. Elle restreint à la fois *qui* peut se connecter et *à quoi* il peut se connecter.

Empêcher la copie ou l'accès aux données d'un projet BigQuery sensible depuis l'extérieur d'une limite réseau fiable, même avec des identifiants valides.

→Configurer les Contrôles de service VPC. Créer un périmètre de service qui inclut le projet sensible et restreint l'API BigQuery.

Pourquoi: Les Contrôles de service VPC créent un "périmètre de données" virtuel qui contrôle l'accès au niveau de l'API, offrant une défense solide contre l'exfiltration de données que les règles de pare-feu ne peuvent pas.

Fournir à une application tierce un accès en lecture temporaire et limité dans le temps à un objet privé spécifique dans un bucket Cloud Storage.

→Générer une URL signée pour l'objet avec un temps d'expiration court (par exemple, 15 minutes) en utilisant un compte de service avec des autorisations de lecture.

Pourquoi: Les URL signées accordent un accès temporaire, objet par objet, sans exiger que la tierce partie possède un compte Google ou des autorisations IAM. C'est la méthode la plus sécurisée pour ce cas d'utilisation.

Un pod GKE doit accéder en toute sécurité aux API Google Cloud (par exemple, Pub/Sub) sans stocker les clés de compte de service comme secrets Kubernetes.

→Activer Workload Identity sur le cluster GKE. Créer un compte de service Google (GSA) et un compte de service Kubernetes (KSA). Lier le KSA au GSA à l'aide d'une politique IAM. Configurer le pod pour utiliser le KSA.

Pourquoi: Workload Identity est le moyen recommandé et sans clé pour les applications GKE de s'authentifier auprès des services Google Cloud. Il mappe les identités KSA aux identités GSA, ce qui est plus sécurisé que la gestion et la rotation des fichiers de clés.

Référence↗

Une politique d'organisation exige que toutes les données d'un bucket Cloud Storage soient chiffrées à l'aide d'une clé de chiffrement que l'organisation contrôle.

→Créer une clé cryptographique dans Cloud KMS. Lors de la création du bucket Cloud Storage, spécifier cette clé comme clé de chiffrement gérée par le client (CMEK).

Pourquoi: CMEK vous donne le contrôle sur la clé utilisée pour le chiffrement, y compris la rotation et la révocation, tout en tirant parti de l'infrastructure de chiffrement gérée de Google.

Permettre aux employés d'utiliser leurs identifiants Active Directory existants sur site pour accéder aux ressources Google Cloud.

→Configurer Cloud Identity pour la fédération avec Active Directory à l'aide de SAML 2.0. Les utilisateurs s'authentifient auprès d'AD, qui affirme ensuite leur identité à Google Cloud pour l'accès.

Pourquoi: La fédération permet l'authentification unique (SSO) et centralise la gestion des identités dans l'IdP existant (Active Directory), évitant ainsi la nécessité de gérer un ensemble de mots de passe séparé dans Google Cloud.

Accorder à un entrepreneur externe un accès temporaire à un projet, qui devrait expirer automatiquement après 30 jours.

→Ajouter l'entrepreneur en tant que membre IAM avec le rôle requis. Ajouter une condition à la liaison de rôle avec un horodatage d'expiration (`request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`).

Pourquoi: Les conditions IAM offrent un contrôle d'accès basé sur les attributs. Les conditions basées sur le temps sont parfaites pour l'accès temporaire, car elles révoquent automatiquement les autorisations sans nettoyage manuel.