La squad sécurité doit auditer les accès IAM et les requêtes BigQuery sans pouvoir lire les données des tables transactionnelles. Quelle configuration IAM recommandez-vous, en respectant les bonnes pratiques Google ?

La bonne pratique Google consiste à utiliser des groupes Cloud Identity plutôt que des comptes individuels, et des rôles prédéfinis plutôt que des rôles personnalisés quand ils couvrent le besoin. Pour la squad sécurité, il faut créer un groupe (ex. grp-security-auditors) et lui attribuer deux rôles prédéfinis : roles/logging.viewer pour accéder aux journaux d'activité et d'audit IAM, et roles/bigquery.dataViewer pour consulter les métadonnées BigQuery (schémas, jobs) sans lire les données des tables. Il ne faut surtout pas attribuer roles/bigquery.dataEditor ou roles/spanner.databaseUser qui donneraient accès aux données métier. Cette combinaison permet d'auditer qui a accédé à quoi et quand, via le journal d'activité filtrable par utilisateur et ressource dans la console GCP, sans exposer les données transactionnelles sensibles.

FinPay doit stocker 800 Go de journaux par mois pendant 3 ans. La contrainte budgétaire est forte et les journaux sont consultés environ 2 fois par an. Quelle solution de stockage choisissez-vous et comment automatisez-vous le cycle de vie des données ?

Coldline Storage est la solution optimale : son coût de stockage est très faible (environ 0,004 $/Go/mois) et est conçu pour des données accédées moins d'une fois par an, ce qui correspond exactement au profil d'accès des journaux d'audit de FinPay (2 fois/an). Sur 3 ans, le volume atteint ~28,8 To (800 Go × 36 mois), ce qui resterait dans le budget. Pour automatiser, il faut configurer une politique de cycle de vie (Object Lifecycle Management) sur le bucket avec deux règles : une règle SetStorageClass vers Coldline basée sur la condition Age=30 jours (les journaux récents peuvent rester en Standard temporairement pour facilité d'accès), et une règle Delete avec Age=1095 jours (3 ans) pour supprimer automatiquement après la durée réglementaire. L'export des journaux Cloud Logging vers ce bucket se fait via un sink natif, sans intermédiaire coûteux (Pub/Sub, Cloud Functions), minimisant ainsi les coûts opérationnels.

L'application 3 niveaux de FinPay sur Compute Engine doit sécuriser les communications inter-niveaux sur le port TCP 8443. Chaque niveau possède son propre compte de service. Comment configurer les règles de pare-feu de manière précise et conforme aux bonnes pratiques GCP ?

La bonne pratique GCP est d'utiliser les comptes de service comme filtres source et cible dans les règles de pare-feu, plutôt que des plages CIDR. Cette approche est plus précise car elle cible exactement les instances associées à un compte de service donné, indépendamment de leur IP. Il faut créer deux règles firewall allow ingress distinctes dans le VPC : (1) une règle autorisant uniquement TCP 8443, ciblant le compte de service du niveau 2 (target service account), avec comme source le compte de service du niveau 1 — cela permet uniquement aux instances frontend d'appeler l'API ; (2) une règle autorisant uniquement TCP 8443, ciblant le compte de service du niveau 3, avec comme source le compte de service du niveau 2. Il ne faut pas créer une règle autorisant tout le trafic (0.0.0.0/0) même sur le port 8443, car cela violerait le principe du moindre privilège requis par les obligations PSD2 de FinPay.

L'équipe constate que lors des scaling events, trop d'instances sont ajoutées inutilement. Le démarrage d'un pod prend 4 minutes mais le health check initial est configuré à 30 secondes. Comment corriger ce comportement et garantir que les pods défaillants soient recréés automatiquement ?

Le problème est un décalage entre le temps réel de démarrage des pods (4 minutes = 240 secondes) et le délai initial du health check (30 secondes). L'autoscaler considère les pods comme prêts après 30 secondes alors qu'ils ne servent pas encore de trafic, ce qui fait monter la charge perçue sur les pods déjà actifs et déclenche l'ajout d'instances supplémentaires inutiles. La solution est d'augmenter le initialDelaySeconds du health check à au moins 250 secondes (240s + marge de sécurité), voire 270 secondes. Sur GKE, cela se configure dans le manifest YAML du Deployment via le champ livenessProbe et readinessProbe avec initialDelaySeconds=250. Pour la recréation automatique des pods défaillants, GKE s'en charge nativement via le ReplicaSet controller : si un pod passe en état non-healthy selon le liveness probe, il est automatiquement redémarré. Il faut également configurer le readinessProbe séparément pour ne pas envoyer de trafic au pod tant qu'il n'est pas vraiment prêt, évitant ainsi les erreurs 503 pendant le démarrage.

ShopFast veut déployer une nouvelle version de son API sur GKE avec une stratégie canary (1% du trafic) puis effectuer un rollout complet sans temps d'arrêt. Quels mécanismes Kubernetes et GKE devez-vous utiliser ? Comment garantir que la capacité totale ne diminue pas pendant la mise à jour ?

Pour le déploiement canary sur GKE, la méthode recommandée est d'utiliser deux Deployments distincts partageant le même label de sélection du Service : le Deployment stable avec N réplicas (ex. 99) et le Deployment canary avec 1 réplica. Le Service Kubernetes distribue le trafic proportionnellement au nombre de pods, donc 1 pod canary sur 100 total = 1% du trafic. Une fois le canary validé (métriques d'erreur, latence), le rollout complet s'effectue via une mise à jour progressive (Rolling Update) sur le Deployment stable. Pour garantir qu'aucune capacité ne diminue pendant la mise à jour, il faut configurer dans la stratégie RollingUpdate du Deployment : maxUnavailable=0 (aucune instance ne peut être indisponible) et maxSurge=1 (une instance supplémentaire est créée avant qu'une ancienne soit supprimée). Cette combinaison garantit que la capacité totale reste toujours >= N pendant toute la durée du déploiement, ce qui est critique pour ShopFast lors des pics de charge. L'exposition en HTTPS publique se fait via un Service de type NodePort combiné à un Ingress GKE qui gère le certificat TLS et l'IP publique.

Les data scientists de ShopFast doivent exécuter des requêtes BigQuery sur les données de commandes. L'équipe change fréquemment. Par ailleurs, le cluster GKE des projets applicatifs doit pouvoir puller les images Docker depuis le projet infra-registry. Comment configurer ces deux accès en respectant les bonnes pratiques Google ?

Pour les data scientists : la bonne pratique Google est de créer un groupe Cloud Identity (ex. grp-data-scientists) plutôt que de gérer des entrées IAM individuelles, ce qui est crucial vu le turnover de l'équipe. Quand un data scientist rejoint ou quitte l'équipe, il suffit de l'ajouter ou le retirer du groupe sans modifier les politiques IAM. Le rôle à attribuer au groupe est roles/bigquery.jobUser sur le projet BigQuery (permet d'exécuter des requêtes/jobs) combiné à roles/bigquery.dataViewer sur les datasets spécifiques aux données de commandes (permet de lire les données). roles/bigquery.dataViewer seul ne suffit pas car il ne permet pas de soumettre des jobs de requête. Pour l'accès aux images Container Registry depuis GKE : il faut accorder le rôle roles/storage.objectViewer au compte de service des noeuds GKE du projet applicatif sur le bucket gs://artifacts.[infra-registry].appspot.com dans le projet infra-registry. Container Registry stocke ses images dans Cloud Storage, donc c'est bien un rôle Storage qui est nécessaire. Cette approche utilise IAM correctement sans créer de clés de service supplémentaires ni donner des accès trop larges au projet infra-registry.

L'équipe a modifié plusieurs templates Deployment Manager complexes simultanément. Le CTO exige de valider les dépendances inter-ressources avant tout déploiement en production. Quelle commande utiliser pour obtenir le retour le plus rapide possible, et comment mettre à jour un déploiement existant sans temps d'arrêt une fois la validation effectuée ?

Pour valider les dépendances sans déployer réellement les ressources, la commande à utiliser est gcloud deployment-manager deployments create [DEPLOYMENT_NAME] --config [CONFIG_FILE] --preview. L'option --preview est fondamentale : elle analyse le template, valide toutes les dépendances déclarées entre ressources, et affiche les ressources qui seraient créées ou modifiées sans les instancier réellement dans le projet. C'est le retour le plus rapide possible car aucune ressource n'est provisionnée (pas d'attente de création de VMs, buckets, etc.). Si la prévisualisation révèle des dépendances manquantes ou incorrectes, l'équipe peut corriger le template sans impact sur la production. Une fois la validation réussie, pour mettre à jour un déploiement existant sans temps d'arrêt, la commande correcte est gcloud deployment-manager deployments update [DEPLOYMENT_NAME] --config [CONFIG_FILE]. Cette commande effectue une mise à jour incrémentale : elle compare l'état actuel avec le nouvel état désiré et ne modifie que les ressources qui ont changé, évitant toute interruption de service inutile sur les ressources non modifiées.

Les jobs de traitement par lots s'exécutent 2 heures par nuit sur Compute Engine. DataSync a un budget limité à 4 500 €/mois. Comment minimiser les coûts pour ces jobs tout en garantissant leur exécution, et comment configurer le serveur de licences pour qu'il soit toujours accessible à l'IP fixe 10.2.0.15 ?

Pour les jobs nocturnes de 2 heures : les instances préemptibles (Spot VMs) sont la solution optimale. Elles coûtent jusqu'à 80% moins cher que les instances standard. Les jobs de traitement par lots nocturnes sont des workloads parfaitement adaptés aux instances préemptibles car : ils sont tolérants aux interruptions (peuvent être relancés), ils s'exécutent sur une courte fenêtre de 2 heures la nuit (période où les ressources GCP sont moins sollicitées, donc moins susceptibles d'être préemptées), et ils ne servent pas de trafic utilisateur en direct. Il faut utiliser un Managed Instance Group avec des instances préemptibles et configurer une automatisation (Cloud Scheduler + Cloud Functions ou gcloud) pour démarrer et arrêter le MIG selon la fenêtre 2h-4h. Cela peut représenter une économie de 300-400 €/mois sur le budget. Pour le serveur de licences à IP fixe : il faut réserver l'adresse IP interne 10.2.0.15 comme IP interne statique dans le VPC avant de créer la VM, puis créer l'instance Compute Engine en lui assignant cette IP réservée. Ainsi, même si la VM redémarre ou est recréée, elle conserve toujours l'IP 10.2.0.15, et tous les microservices du VPC peuvent s'y connecter sans modifier leur configuration.

Des clients partenaires de DataSync, sans compte Google, doivent accéder temporairement (4 heures) à des rapports PDF confidentiels stockés dans Cloud Storage. Par ailleurs, l'application Cloud Run doit traiter des messages Pub/Sub. Comment sécuriser ces deux accès de manière optimale ?

Pour l'accès temporaire des partenaires aux rapports PDF : la solution la plus sécurisée et la plus simple est de générer une URL signée (Signed URL) pour chaque rapport. Une URL signée donne un accès limité dans le temps (paramètre expiration=4h) à un objet Cloud Storage spécifique, sans nécessiter de compte Google côté partenaire. L'accès expire automatiquement à l'heure définie, sans aucune action manuelle supplémentaire. Il ne faut pas rendre le bucket public ni créer des comptes temporaires — ce serait moins sécurisé et plus complexe. La génération de l'URL signée se fait avec gsutil signurl ou via les librairies clientes GCP en utilisant les credentials d'un compte de service ayant roles/storage.objectViewer sur le bucket. Pour l'intégration Cloud Run / Pub/Sub : la bonne pratique Google est de configurer un abonnement Pub/Sub en mode push vers l'URL du service Cloud Run. Il faut créer un compte de service dédié et lui accorder le rôle roles/run.invoker sur le service Cloud Run. Pub/Sub utilisera ce compte de service pour s'authentifier lors des appels push vers Cloud Run. Cette approche évite la gestion d'un processus pull dans l'application, est la méthode officiellement recommandée par Google, et respecte le principe du moindre privilège (le compte de service Pub/Sub ne peut qu'invoquer ce service Cloud Run spécifique).

L'équipe support de 4 personnes doit surveiller les métriques de performance Cloud Spanner et les tableaux de bord des 23 projets depuis une console centralisée, sans jamais avoir accès aux données des dossiers patients. Comment architecturer cette surveillance et quels rôles IAM attribuer ?

Pour la surveillance centralisée des 23 projets, la solution recommandée est de configurer un seul compte Stackdriver Monitoring (Cloud Monitoring) en le liant à tous les projets de l'organisation. Cela permet de consolider toutes les métriques, alertes et tableaux de bord dans une interface unique, sans devoir basculer entre les projets. C'est l'approche officielle Google pour le monitoring multi-projets. Pour les permissions de l'équipe support, il faut créer un groupe Cloud Identity (ex. grp-support-monitoring) et lui attribuer le rôle roles/monitoring.viewer sur l'ensemble des projets (ou au niveau organisation). Ce rôle permet de consulter toutes les métriques de performance, les tableaux de bord et les alertes Cloud Monitoring / Spanner, sans donner aucun accès aux données des tables. Il est impératif de ne pas attribuer roles/spanner.databaseUser, roles/spanner.databaseReader ou tout rôle Cloud Spanner data plane, qui donneraient accès aux dossiers patients en violation du RGPD et des réglementations de santé. L'utilisation d'un groupe (plutôt que 4 entrées IAM individuelles) simplifie la gestion des rotations dans l'équipe support.

Le RSSI exige que les mots de passe et credentials ne soient plus stockés en clair dans les fichiers YAML des déploiements GKE. Comment refactoriser la gestion des secrets dans les manifests Kubernetes, et comment s'assurer que l'agent de monitoring tiers s'exécute sur chaque noeud du cluster GKE (y compris les nouveaux noeuds créés par l'autoscaling) ?

Pour la gestion des secrets dans GKE : il faut remplacer toute valeur sensible en clair dans les fichiers YAML par des références à des Kubernetes Secrets. La refactorisation consiste à créer un Secret Kubernetes (kubectl create secret generic db-credentials --from-literal=password=[VALEUR]) puis à le référencer dans le Deployment via env.valueFrom.secretKeyRef ou en le montant comme volume. Les Secrets sont encodés en base64 et stockés dans etcd (idéalement avec encryption at rest activée dans GKE). Il ne faut pas utiliser les ConfigMaps pour les données sensibles car ils ne sont pas conçus pour cela et ne bénéficient pas des contrôles d'accès spécifiques des Secrets. Pour empêcher que les Secrets réapparaissent dans Git, il faut ajouter des règles dans .gitignore et idéalement intégrer un outil de détection de secrets dans la pipeline CI/CD. Pour l'agent de monitoring tiers sur chaque noeud GKE : la ressource Kubernetes à utiliser est un DaemonSet. Un DaemonSet garantit qu'exactement un pod s'exécute sur chaque noeud du cluster, y compris automatiquement sur les nouveaux noeuds créés par le Cluster Autoscaler lors des pics d'activité. C'est la ressource conçue précisément pour les agents système per-noeud (monitoring, logging, sécurité). Un Deployment avec réplicas fixes ne conviendrait pas car le nombre de noeuds varie dynamiquement.

Les serveurs d'imagerie médicale tournent sur des Managed Instance Groups. Une nouvelle version du logiciel doit être déployée progressivement sans réduire la capacité disponible. Par ailleurs, certains VMs tombent en panne silencieusement (le processus s'arrête mais la VM reste allumée) et ne sont pas recréées automatiquement. Comment résoudre ces deux problèmes ?

Pour le déploiement progressif sans réduction de capacité : il faut configurer la politique de mise à jour du MIG avec maxSurge=1 et maxUnavailable=0. maxUnavailable=0 signifie qu'aucune instance ne peut être mise hors service tant qu'une nouvelle instance de remplacement n'est pas opérationnelle. maxSurge=1 autorise la création d'une instance supplémentaire temporaire pendant la transition. Avec cette configuration, le MIG crée d'abord la nouvelle instance avec la nouvelle version, attend qu'elle soit healthy, puis retire l'ancienne — garantissant que la capacité totale ne diminue jamais, ce qui est critique pour les serveurs d'imagerie médicale en usage clinique. Pour les pannes silencieuses (processus arrêté mais VM active) : la solution est de configurer un health check d'Autohealing sur le MIG. Il faut créer un health check HTTP/HTTPS sur le port applicatif du logiciel d'imagerie (ex. port 8080 ou 443) avec une vérification toutes les 10 secondes et un seuil de 3 tentatives échouées avant de considérer l'instance comme défaillante. En attachant ce health check au MIG avec une politique d'Autohealing, GCP recréera automatiquement toute instance qui ne répond plus au health check, même si la VM elle-même est techniquement active. C'est différent du simple redémarrage automatique qui ne détecte que les crashes système, pas les défaillances applicatives.

Les data analysts exécutent des requêtes BigQuery coûteuses sur des tables de plusieurs téraoctets sans contrôle préalable. Comment permettre aux analysts d'estimer le coût d'une requête avant de l'exécuter ? Par ailleurs, l'équipe veut analyser les coûts de facturation de 3 projets GCP distincts avec des requêtes SQL standard, par type de service, quotidiennement et mensuellement. Quelle architecture recommandez-vous ?

Pour l'estimation des coûts avant exécution : la commande à utiliser est bq query --dry_run '[REQUÊTE SQL]'. L'option --dry_run estime les octets qui seraient lus (scannés) par la requête sans l'exécuter réellement. Attention : dans la tarification à la demande BigQuery, la facturation est basée sur les octets lus depuis les tables, pas sur les octets retournés dans le résultat. Une requête SELECT * sur une table de 5 To coûtera pour 5 To lus même si elle ne retourne que 100 lignes. L'équipe doit intégrer cette vérification dans son workflow : toute requête exploratoire sur une table > 100 Go doit passer par --dry_run avant soumission. Pour l'analyse des coûts de facturation multi-projets : BigQuery est la solution recommandée. Il faut configurer l'export de facturation GCP (Billing Export) vers un dataset BigQuery depuis la console Cloud Billing, en activant l'export pour les 3 projets. BigQuery supporte nativement le SQL standard (BigQuery SQL), les fonctions de fenêtrage temporel (DATE_TRUNC pour agréger par jour/mois), les JOINs entre tables, et peut interroger les données de plusieurs projets dans une seule requête. Cloud Storage ne permet pas de requêtes SQL directes sur les données de facturation, ce serait inadapté pour ce besoin d'analyse structurée.

StreamPress veut tester le nouveau player vidéo sur 1% des utilisateurs d'App Engine avant déploiement complet, corriger le problème d'affichage des PDF dans les navigateurs, et automatiser l'archivage des vidéos (Coldline après 90 jours, suppression après 2 ans). Comment configurer ces trois éléments ?

Pour le déploiement canary App Engine à 1% : App Engine permet nativement le fractionnement de trafic (traffic splitting) entre plusieurs versions d'une même application. Il suffit de déployer la nouvelle version du player (ex. v2) sans lui affecter de trafic, puis d'utiliser la commande gcloud app services set-traffic default --splits v1=99,v2=1 ou de configurer le fractionnement dans la console GCP via la page Versions. C'est la solution la plus simple car elle ne nécessite pas de créer une nouvelle application — tout reste dans le même projet App Engine. Une fois les métriques d'engagement validées, le trafic est basculé à 100% vers v2 en une seule opération. Pour le problème d'affichage des PDF : le navigateur décide d'afficher ou de télécharger un fichier selon l'en-tête HTTP Content-Type reçu. Actuellement, les PDFs ont probablement le Content-Type application/octet-stream ou aucun type défini, ce qui force le téléchargement. La solution est de modifier les métadonnées des objets PDF dans Cloud Storage pour définir Content-Type=application/pdf. Avec cet en-tête, tous les navigateurs modernes afficheront le PDF directement dans l'onglet. Pour l'archivage automatique des vidéos : configurer une politique de cycle de vie (Object Lifecycle Management) sur le bucket Cloud Storage avec deux règles basées sur la condition Age (nombre de jours depuis la création de l'objet) : règle 1 — SetStorageClass: Coldline avec Age=90 (après 90 jours, la vidéo passe en Coldline) ; règle 2 — Delete avec Age=730 (après 730 jours = 2 ans depuis la création, la vidéo est supprimée). Les deux conditions sont calculées depuis la date de création originale de l'objet, pas depuis le changement de classe de stockage.

StreamPress veut construire un pipeline temps réel pour les événements de lecture vidéo. Ces événements doivent être ingérés en flux, traités pour calculer des métriques d'engagement (taux de complétion, points d'abandon), stockés pour des requêtes temporelles haute performance, puis disponibles pour l'analyse SQL ad hoc. Quels services GCP placer à chaque étape du pipeline et pourquoi ?

Le pipeline optimal pour les séries temporelles d'événements vidéo suit l'architecture standard GCP pour le streaming analytics, avec 4 étapes : Étape 1 — Ingestion : Cloud Pub/Sub. C'est le service d'ingestion de messages en temps réel de GCP. Le player vidéo publie chaque événement (play, pause, seek, buffering avec timestamp et user_id) dans un topic Pub/Sub. Pub/Sub garantit la livraison, découple les producteurs des consommateurs, et absorbe les pics de trafic (ex. lors d'une sortie de contenu populaire générant des millions d'événements simultanés). Étape 2 — Traitement : Cloud Dataflow. Dataflow est le service de traitement de flux (et batch) managé de GCP, basé sur Apache Beam. Il permet de calculer les métriques d'engagement en temps réel : fenêtres glissantes pour le taux de complétion par vidéo, détection des points d'abandon fréquents, agrégations par utilisateur/session. Dataflow s'intègre nativement avec Pub/Sub en entrée et Bigtable/BigQuery en sortie. Étape 3 — Stockage temps réel : Cloud Bigtable. Bigtable est conçu spécifiquement pour les séries temporelles haute performance : latence < 10ms, scalabilité horizontale, modèle de données orienté lignes avec clé composée (video_id + timestamp). Il est idéal pour les requêtes temporelles type 'métriques d'engagement des 24 dernières heures pour la vidéo X'. Étape 4 — Analyse SQL ad hoc : BigQuery. Dataflow écrit également les données agrégées dans BigQuery pour l'analyse historique. BigQuery supporte le SQL standard, les fenêtres temporelles, et permet aux data analysts de StreamPress d'interroger des mois d'historique d'engagement sans gérer l'infrastructure.