← Blog
Questions d'Entretien GCP : Guide Complet avec Réponses (2026)
seo

Questions d'Entretien GCP : Guide Complet avec Réponses (2026)

20 questions d'entretien Google Cloud Platform avec des frameworks de réponse détaillés, des fondamentaux aux scénarios avancés.

· 20 min de lecture

Questions d’Entretien GCP : Guide Complet avec Réponses (2026)

J’ai failli rater mon premier entretien Google Cloud. Pas par manque de connaissances — j’utilisais GCP en production depuis deux ans. Le problème, c’est que je répondais comme si je récitais de la documentation au lieu de parler comme quelqu’un qui avait réellement opéré la plateforme.

L’intervieweuse m’a posé une question sur Cloud Spanner. J’ai débité les caractéristiques techniques. Distribué globalement, fortement cohérent, relationnel. Tout était correct. Tout était ennuyeux. Ce qu’elle voulait vraiment entendre, c’était pourquoi je choisirais Spanner plutôt que Cloud SQL pour un cas précis, quelles étaient les implications de coût, et si j’avais déjà été surpris par son modèle de tarification. Je n’étais pas préparé à ce type de conversation.

Cette expérience a changé ma façon d’aborder les entretiens GCP. Les questions ne portent pas sur l’existence des services. Elles vérifient si vous avez pris de vraies décisions avec. Voici 20 questions que j’ai rencontrées régulièrement — classées par niveau — avec les frameworks de réponse qui fonctionnent réellement.

Fondamentaux : Les Questions Qui Semblent Faciles Jusqu’à Ce Qu’elles Ne Le Soient Plus

1. Qu’est-ce que Google Cloud Platform et comment fonctionne son infrastructure globale ?

Quoi dire : GCP organise les ressources en régions et zones. Une région est un emplacement géographique (comme europe-west1). Chaque région possède au moins trois zones, qui sont des domaines de défaillance isolés. Les ressources comme les instances Compute Engine vivent dans une zone spécifique. Certains services — Cloud Storage, BigQuery — sont multi-régionaux ou globaux par conception, ce qui change la façon dont on pense la disponibilité.

Erreur courante : Décrire les régions et zones comme si elles étaient interchangeables avec AWS. Ce n’est pas le cas. Le réseau de GCP est construit sur la fibre privée de Google, et le modèle réseau plat signifie que les réseaux VPC sont globaux par défaut — pas régionaux comme les VPC AWS. Cette distinction compte dans les discussions d’architecture.

2. Expliquez la différence entre Compute Engine, App Engine, Cloud Run et Cloud Functions.

Quoi dire : C’est un spectre entre contrôle et commodité. Compute Engine donne des VM complètes — vous gérez tout. App Engine est un PaaS qui gère le scaling et le déploiement pour les runtimes standards. Cloud Run exécute des conteneurs stateless sans gestion d’infrastructure — vous apportez une image Docker, il s’occupe du reste. Cloud Functions est piloté par événements : écrivez une fonction, attachez un déclencheur, c’est fait. La décision dépend de la charge opérationnelle que votre équipe peut absorber.

Erreur courante : Traiter Cloud Run et Cloud Functions comme la même chose. Cloud Run gère des conteneurs arbitraires avec HTTP ou gRPC, supporte la concurrence par instance et peut fonctionner jusqu’à 60 minutes. Cloud Functions est mono-usage, déclenché par événement, avec un temps d’exécution plus limité. Savoir quand chaque option convient est la vraie compétence testée.

3. Comment fonctionne IAM dans GCP ?

Quoi dire : IAM de GCP suit une hiérarchie de ressources : Organisation > Dossiers > Projets > Ressources. Les politiques sont héritées vers le bas. On attribue des rôles aux membres (utilisateurs, groupes, comptes de service). Les rôles sont des collections de permissions. Il y a les rôles basiques (Owner, Editor, Viewer), les rôles prédéfinis (granulaires par service) et les rôles personnalisés. Préférez toujours les rôles prédéfinis aux basiques — Editor accorde beaucoup trop d’accès pour la plupart des cas d’usage.

Erreur courante : Ignorer la hiérarchie. Un rôle accordé au niveau de l’organisation se propage à chaque projet en dessous. J’ai vu des équipes accorder Editor au niveau org “par commodité” et créer un cauchemar de sécurité. Accordez toujours les permissions au périmètre le plus étroit possible.

4. Qu’est-ce qu’un VPC dans GCP et en quoi diffère-t-il des autres fournisseurs cloud ?

Quoi dire : Un VPC GCP est global. C’est la différence clé. Vous créez un VPC et ajoutez des sous-réseaux dans n’importe quelle région — pas besoin de peering VPC entre régions dans le même réseau. Les sous-réseaux sont régionaux et utilisent des plages CIDR. Les règles de pare-feu s’appliquent au niveau réseau via des tags ou des comptes de service, pas attachées individuellement aux instances comme les security groups dans AWS.

Erreur courante : Concevoir le réseau GCP comme si c’était AWS. Chez AWS, vous créez un VPC par région et les connectez par peering. Chez GCP, un seul VPC avec des sous-réseaux régionaux suffit souvent. Lutter contre le modèle GCP au lieu de l’adopter crée une complexité inutile.

5. Qu’est-ce que Cloud Storage et comment fonctionnent les classes de stockage ?

Quoi dire : Cloud Storage est le service de stockage objet de GCP — équivalent de S3. Les objets vont dans des buckets. Les classes de stockage contrôlent le coût et la disponibilité : Standard pour les accès fréquents, Nearline pour les accès mensuels, Coldline pour les trimestriels et Archive pour les annuels. Vous pouvez définir des politiques de cycle de vie pour transitionner automatiquement les objets entre classes.

Erreur courante : Oublier les coûts de sortie réseau. Le stockage en Coldline peut être bon marché, mais les frais de récupération et d’egress s’accumulent vite si vos patterns d’accès ne correspondent pas à la classe choisie. J’ai vu des équipes économiser 200 $/mois en stockage puis dépenser 800 $ en récupérations imprévues.

Intermédiaire : Prouver Que Vous Avez Réellement Construit des Choses

6. Comment concevriez-vous un pipeline CI/CD sur GCP ?

Quoi dire : Cloud Build est le service CI/CD natif de GCP. Vous définissez les étapes dans un fichier cloudbuild.yaml. Un pipeline typique : déclencher sur un push vers un dépôt GitHub, exécuter les tests, construire une image Docker, la pousser vers Artifact Registry, déployer sur Cloud Run ou GKE. Pour des workflows plus complexes, chaîner des triggers Cloud Build ou intégrer Pub/Sub pour des pipelines event-driven. Secret Manager gère les credentials pendant les builds.

Erreur courante : Trop compliquer les choses. Certains candidats sautent immédiatement vers Jenkins sur GKE ou des outils tiers. Si l’intervieweur demande le CI/CD natif GCP, commencez par Cloud Build. Mentionnez ensuite que pour des besoins d’orchestration complexes — promotion multi-environnement, gates d’approbation — vous pourriez introduire Spinnaker ou Argo CD sur GKE.

7. Quand choisiriez-vous BigQuery plutôt que Cloud SQL ou Cloud Spanner ?

Quoi dire : BigQuery est un data warehouse serverless optimisé pour les requêtes analytiques sur des datasets massifs. Cloud SQL est du MySQL/PostgreSQL managé pour les charges transactionnelles. Cloud Spanner est distribué globalement, fortement cohérent et relationnel — c’est pour quand vous avez besoin à la fois de scale horizontale et de transactions ACID. L’arbre de décision : OLTP à échelle modérée ? Cloud SQL. OLTP à échelle globale avec cohérence forte ? Spanner. Analytics et reporting sur des téraoctets de données ? BigQuery.

Erreur courante : Suggérer BigQuery pour des charges transactionnelles. BigQuery est colonnaire et optimisé pour les scans, pas les lookups ponctuels ou les petites écritures fréquentes. L’utiliser comme base de données primaire pour une application serait une erreur architecturale coûteuse.

8. Expliquez Pub/Sub et quand vous l’utiliseriez.

Quoi dire : Pub/Sub est un service de messagerie managé pour la communication asynchrone. Les éditeurs envoient des messages vers des topics, les abonnés tirent depuis des abonnements. Il garantit une livraison au-moins-une-fois avec des délais d’acquittement configurables. À utiliser pour : découpler les microservices, architectures event-driven, ingestion de données en streaming (en combinaison avec Dataflow), et tampon entre systèmes ayant des débits différents.

Erreur courante : Ne pas mentionner l’ordonnancement et la sémantique d’exactement-une-fois. Pub/Sub supporte désormais les clés d’ordonnancement pour la livraison ordonnée au sein d’une clé, et la livraison exactement-une-fois pour les abonnements pull. Si l’intervieweur demande l’ordonnancement des événements, vous devez savoir que ces fonctionnalités existent — et qu’elles viennent avec des compromis de débit.

9. Comment gérez-vous l’infrastructure as code sur GCP ?

Quoi dire : Terraform est le choix le plus courant — il est agnostique du cloud et le provider GCP est mature. Google propose aussi Deployment Manager (natif mais limité) et Config Connector (Kubernetes-natif, gère les ressources GCP via des CRDs). Pour Terraform, stockez l’état dans un backend GCS avec versioning et verrouillage d’état via les mécanismes intégrés de Cloud Storage.

Erreur courante : Ignorer la gestion de l’état. J’ai vu des équipes utiliser un état Terraform local sur une VM partagée et le corrompre en une semaine. Un état distant dans GCS avec un pipeline CI/CD qui exécute terraform plan sur les PRs — c’est le pattern qui survit aux dynamiques d’équipe réelles.

10. Quelle est la différence entre GKE Standard et GKE Autopilot ?

Quoi dire : GKE Standard donne un contrôle complet sur les nœuds — vous gérez les pools de nœuds, les types de machines, les politiques de scaling, le patching OS. GKE Autopilot supprime la gestion des nœuds : Google provisionne et scale les nœuds en fonction de vos specs de pods. Vous payez par requête de ressource de pod, pas par nœud. Autopilot applique les bonnes pratiques de sécurité par défaut (pas de pods privilégiés, pas d’accès réseau hôte). Choisissez Standard pour les workloads GPU, les types de machines spécifiques ou les DaemonSets qu’Autopilot restreint. Choisissez Autopilot quand vous voulez vous concentrer sur les workloads, pas l’infrastructure.

Erreur courante : Rejeter Autopilot comme “pas prêt pour la production”. Il l’est. Google y fait tourner des workloads significatifs. La vraie limitation concerne les personnalisations spécifiques — paramètres kernel custom, certains drivers CSI, ou workloads nécessitant un accès privilégié. Connaissez les contraintes, ne rejetez pas l’option.

Avancé : Là Où l’Expérience Réelle Se Voit

11. Concevez une application distribuée globalement sur GCP.

Quoi dire : Utilisez Cloud Spanner pour la couche base de données — c’est la seule base relationnelle qui offre une cohérence forte globale. Déployez l’application sur des clusters GKE dans plusieurs régions avec Multi Cluster Ingress ou Cloud Load Balancing avec un Application Load Balancer externe global. Cloud CDN pour le contenu statique. Cloud Armor pour la protection DDoS et les règles WAF. Pub/Sub pour la propagation d’événements inter-régions. Cloud DNS avec routage par géolocalisation pour diriger les utilisateurs vers la région la plus proche.

Erreur courante : Oublier la conversation sur les coûts. Cloud Spanner à échelle globale est cher — les configurations multi-régions commencent à un minimum de nœuds qui peut coûter des milliers d’euros par mois. Une bonne réponse reconnaît cela et mentionne que pour certains cas d’usage, Firestore en mode multi-région ou une architecture Cloud SQL avec réplicas de lecture pourrait suffire à une fraction du coût.

12. Comment implémenteriez-vous la sécurité zero-trust sur GCP ?

Quoi dire : BeyondCorp Enterprise est le framework zero-trust de Google. Utilisez Identity-Aware Proxy (IAP) pour contrôler l’accès aux applications sans VPN — chaque requête est authentifiée et autorisée selon l’identité de l’utilisateur et le contexte de l’appareil. VPC Service Controls crée des périmètres de sécurité autour des API sensibles. Workload Identity pour que les pods GKE assument des identités de comptes de service sans fichiers de clés. Binary Authorization garantit que seules les images de conteneurs approuvées se déploient sur vos clusters.

Erreur courante : Réduire le zero-trust à “utilisez juste IAP”. Le zero-trust est une stratégie en couches : vérification d’identité (IAP, Identity Platform), vérification de posture d’appareil (BeyondCorp), segmentation réseau (VPC Service Controls), protection des données (API DLP, CMEK), et surveillance continue (Security Command Center). Mentionner une seule couche montre une compréhension superficielle.

13. Expliquez l’architecture de Cloud Spanner et quand il vaut son coût.

Quoi dire : Spanner utilise TrueTime — des horloges atomiques synchronisées et des récepteurs GPS dans chaque datacenter Google — pour atteindre la cohérence externe entre des réplicas globaux sans les goulots d’étranglement traditionnels du consensus. Les données sont shardées en splits, et chaque split a un groupe Paxos. Le coût se justifie quand vous avez besoin simultanément de scale globale, de cohérence forte et de sémantique relationnelle — systèmes de transactions financières, gestion d’inventaire mondiale, ou classements de jeux à très grande échelle.

Erreur courante : Ne pas être honnête sur les inconvénients. Spanner exige une conception de schéma soignée — tables entrelacées, choix de bonnes clés primaires pour éviter les hotspots. La courbe d’apprentissage est raide comparée à Cloud SQL. Et le coût minimum pour une instance multi-région en production est significatif. Si vos données tiennent dans une seule région et que vous n’avez pas besoin d’écritures globales, Cloud SQL avec des réplicas de lecture est souvent le choix pragmatique.

14. Comment optimisez-vous les coûts sur GCP ?

Quoi dire : Commencez par les exports de facturation vers BigQuery — cela donne des données de coûts requêtables. Utilisez les remises d’engagement (CUD) pour les workloads prévisibles Compute Engine et Cloud SQL. VMs préemptibles (ou Spot VMs) pour le traitement batch tolérant aux pannes. Redimensionnez les instances avec les suggestions de l’API Recommender. Configurez des alertes de budget. Pour GKE, utilisez le cluster autoscaler et le vertical pod autoscaler pour éviter le sur-provisionnement. Révisez et supprimez les ressources inutilisées — VMs inactives, disques persistants orphelins, anciens snapshots.

Erreur courante : Se focaliser uniquement sur le compute. Les coûts de stockage, d’egress réseau et de logging/monitoring surprennent souvent les équipes. La tarification à la demande de BigQuery peut exploser avec des requêtes mal écrites qui scannent des tables entières — utilisez le partitionnement, le clustering et les réservations de slots pour des coûts analytics prévisibles.

15. Guidez-moi dans le débogage d’un problème de latence dans une architecture microservices sur GKE.

Quoi dire : Commencez par les dashboards Cloud Monitoring et les SLOs pour identifier quel service est lent. Utilisez Cloud Trace pour voir les traces distribuées entre services et localiser le goulot d’étranglement. Vérifiez Cloud Logging pour les pics d’erreurs. Coupables courants : délais de résolution DNS (vérifiez la configuration ndots dans les pods), requests de ressources mal configurées causant du throttling CPU, cold starts dans les déploiements auto-scalés, ou un service en aval atteignant la limite de son pool de connexions. Utilisez kubectl top pods et l’état du Horizontal Pod Autoscaler pour vérifier la pression sur les ressources.

Erreur courante : Sauter directement au débogage au niveau code sans vérifier l’infrastructure d’abord. Neuf fois sur dix, les problèmes de latence dans GKE viennent des limites de ressources, des network policies, ou de probes mal configurées — pas de la logique applicative.

Scénarios : Réfléchir à des Problèmes Réels

16. Votre service Cloud Run fait des timeouts pendant les pics de trafic. Que faites-vous ?

Quoi dire : Vérifiez le paramètre de concurrence par instance — s’il est à 1, chaque instance gère une seule requête, créant une pression massive de scale-up. Augmentez-le pour correspondre à ce que votre conteneur peut supporter (80-100 pour des API stateless est courant). Vérifiez la limite d’instances maximum — elle plafonne peut-être le scaling. Examinez les temps de cold start : utilisez des instances minimum pour garder des conteneurs chauds. Si le service dépend d’une base de données, vérifiez le connection pooling — Cloud SQL Auth Proxy avec des limites de connexion empêche l’épuisement du pool.

Erreur courante : Suggérer immédiatement une migration vers GKE. Cloud Run peut gérer la plupart des défis de scaling avec une configuration adéquate. La solution est généralement les paramètres de concurrence, les instances minimum, ou les goulots d’étranglement en aval — pas une migration de plateforme.

17. Vous devez migrer une application legacy on-premise vers GCP. Comment procédez-vous ?

Quoi dire : Commencez par l’évaluation avec Migration Center pour découvrir et analyser l’environnement existant. Phase un : lift-and-shift des VMs vers Compute Engine avec Migrate to Virtual Machines. Cela vous met dans le cloud rapidement avec un minimum de changements. Phase deux : moderniser incrémentalement — conteneuriser les services pour GKE ou Cloud Run, remplacer les bases de données auto-gérées par Cloud SQL ou Firestore, déplacer le stockage fichier vers Cloud Storage. Transfer Appliance pour les gros volumes de données et Database Migration Service pour les données structurées.

Erreur courante : Proposer une réécriture complète comme première étape. Les migrations échouent quand les équipes essaient de tout moderniser simultanément. Lift-and-shift d’abord, stabiliser, puis moderniser les composants qui bénéficient le plus des services cloud-natifs. Le pattern Strangler Fig fonctionne ici aussi.

18. Une requête BigQuery qui prenait 10 secondes prend maintenant 5 minutes. Que s’est-il passé ?

Quoi dire : Vérifiez si le volume de données de la table a significativement augmenté. Regardez le plan d’exécution pour des scans de table complète — la table a peut-être besoin de partitionnement (par date le plus souvent) ou de clustering (par colonnes fréquemment filtrées). Vérifiez si quelqu’un a supprimé une vue matérialisée qui servait la requête. Examinez l’utilisation des slots — en tarification à la demande, vous partagez les slots avec d’autres projets et pourriez être en file d’attente. Considérez des slots réservés pour des performances constantes. Vérifiez aussi les changements de schéma récents qui auraient pu invalider le partition pruning.

Erreur courante : Ne pas vérifier la cause la plus simple d’abord : quelqu’un a peut-être modifié la requête elle-même ou supprimé une clause WHERE qui filtrait les partitions. Comparez toujours la requête lente à la version précédente avant d’investiguer l’infrastructure.

19. Concevez un pipeline de données event-driven pour de l’analytics en temps réel.

Quoi dire : Pub/Sub ingère les événements des producteurs. Dataflow (Apache Beam managé) traite le flux — transformations, enrichissement, fenêtrage. Écriture des résultats vers BigQuery pour l’analytics et les dashboards. Pour des exigences de latence sub-seconde, écrire aussi vers Bigtable pour le serving. Cloud Monitoring pour suivre le lag du pipeline. Des topics dead-letter dans Pub/Sub gèrent les messages empoisonnés. Schema Registry (ou simplement la validation de schéma sur les topics Pub/Sub) assure la qualité des données à la source.

Erreur courante : Ignorer la backpressure et la gestion des erreurs. Un pipeline de production a besoin de files de messages morts, de politiques de retry et de monitoring du lag consommateur. Les candidats qui ne décrivent que le chemin nominal n’ont pas opéré un pipeline à grande échelle.

20. Votre équipe veut utiliser plusieurs projets GCP pour différents environnements. Comment organisez-vous cela ?

Quoi dire : Utilisez une hiérarchie de ressources : Organisation > Dossiers (par département ou équipe) > Projets (dev, staging, prod par service). Appliquez des politiques d’organisation au niveau des dossiers — restreindre les régions, imposer les labels, désactiver la création d’IP externes en prod. Shared VPC pour centraliser le réseau : le projet hôte possède le VPC, les projets de service déploient leurs ressources dans des sous-réseaux partagés. Modules Terraform avec des fichiers de variables par environnement pour garder l’infrastructure cohérente. Les pipelines CI/CD déploient vers chaque projet avec des comptes de service spécifiques à l’environnement.

Erreur courante : Créer des VPC séparés par projet puis lutter avec la connectivité. Shared VPC est la réponse de GCP au réseau inter-projets et évite le spaghetti de peering qui vient avec un VPC par projet.

Services GCP à Connaître Absolument

Au-delà des services couverts dans les questions ci-dessus, assurez-vous de pouvoir parler avec confiance de ceux-ci :

Vous n’avez pas besoin d’une expertise approfondie sur chacun. Mais vous devez savoir quel problème chacun résout et quand vous l’utiliseriez plutôt qu’une alternative.

Utiliser le GCP Free Tier pour S’entraîner

Voici un conseil pratique qui a fait la différence dans ma propre préparation : utilisez le GCP free tier pour construire des choses réelles, pas juste pour en lire à leur sujet.

Google propose un free tier généreux qui inclut :

C’est assez pour construire une architecture event-driven complète sans dépenser un centime. Voici ce que je construirais : une Cloud Function qui publie des événements vers Pub/Sub, un service Cloud Run qui les traite, BigQuery pour l’analytics, et Firestore pour l’état applicatif. Vous rencontrerez de vrais problèmes — configuration IAM, réseau, cold starts — qui vous préparent aux conversations d’entretien bien mieux que les tutoriels ne le feront jamais.

Un point d’attention : le free tier a des limites spécifiques par service, et les dépasser génère des frais. Configurez des alertes de budget immédiatement après avoir créé votre projet. J’ai mis les miennes à 5 $ avec des notifications par email. Cela a rattrapé des dépassements accidentels plus d’une fois.

Les 300 $ de crédits gratuits pour les nouveaux comptes couvrent ce que le free tier permanent ne couvre pas. Utilisez-les pour expérimenter avec GKE et Cloud Spanner — ceux-ci sont trop chers à explorer sans crédits.

FAQ

Combien de certifications GCP faut-il avoir avant de passer un entretien ?

Une certification pertinente suffit généralement pour passer les filtres de CV. L’Associate Cloud Engineer ou le Professional Cloud Architect sont les plus reconnus. Mais les certifications seules ne font pas réussir les entretiens — j’ai rencontré des candidats certifiés incapables de concevoir un VPC basique. Associez le certificat à des projets pratiques dont vous pouvez parler en détail.

Est-ce que les entretiens GCP sont plus difficiles que ceux AWS ?

La difficulté est comparable, mais le style diffère. Les entretiens GCP mettent davantage l’accent sur l’ingénierie de données et l’analytics, reflétant la dominance de BigQuery dans l’écosystème. Les entretiens AWS penchent plus vers la largeur opérationnelle. Si vous passez un entretien dans une entreprise qui a choisi GCP, attendez-vous à des questions sur BigQuery, Pub/Sub et Dataflow — la stack data de Google est généralement la raison pour laquelle ils ont choisi GCP.

Faut-il apprendre Kubernetes pour un entretien GCP ?

Si le poste implique GKE, absolument. GKE est le service d’orchestration de conteneurs phare de GCP et de nombreuses entreprises GCP utilisent intensivement Kubernetes. Vous devez comprendre les pods, deployments, services, ingress, namespaces et l’autoscaling au minimum. Pour les postes seniors, préparez-vous à des questions sur Istio/Anthos Service Mesh, Workload Identity et la gestion multi-cluster.

Quelle est la plus grande erreur que font les candidats en entretien GCP ?

Traiter GCP comme “AWS avec des noms différents”. GCP a des opinions architecturales véritablement différentes — VPC globaux, isolation des ressources basée sur les projets, le modèle serverless de BigQuery, TrueTime de Cloud Spanner. Les candidats qui traduisent juste les concepts AWS sans comprendre les patterns natifs de GCP passent pour superficiels. Apprenez pourquoi GCP a fait des choix de conception différents, pas seulement quels sont les services équivalents.

Vous voulez une préparation cloud plus large ? Ces questions GCP font partie d’un tableau plus grand. Pour des questions cloud générales couvrant les trois fournisseurs, lisez Top 15 Questions d’Entretien Cloud (AWS, Azure, GCP).

Besoin d’une stratégie d’entretien complète ? Les questions techniques ne sont qu’une pièce du puzzle. Pour le plan complet — coding, system design, comportemental, et timing — consultez comment préparer un entretien technique en 2026.

Fini de lire ? Rejoindre l’accès anticipé —>

Prêt(e) à réussir votre prochain entretien ?

Rejoignez l'accès anticipé et soyez parmi les premiers à tester SkillRealm Interview.

Jamais de spam. Désabonnement libre.

questions entretien GCP 2026 preparation entretien google cloud platform questions certification GCP entretien guide entretien ingenieur google cloud