GKE, Terraform et GitLab CI reviennent dans la plupart des offres d'ingénieur DevOps GCP, souvent avec Prometheus, Grafana et OpenTelemetry pour la supervision. Certaines ajoutent OpenShift ou une forte part d'administration Linux. Les questions d'entretien pour un ingénieur DevOps GCP dépendent de l'endroit où tournent les services : sur GKE, sur Cloud Run ou sur les deux, le poste change.
GCP a ses propres règles. Les droits s'héritent de l'organisation vers les dossiers puis les projets, le VPC est global et souvent partagé entre projets, les pods GKE obtiennent leurs droits par Workload Identity Federation for GKE. Un profil venu d'AWS reconnaît les services mais bute souvent sur ces points. Une question sur un rôle accordé au niveau d'un dossier suffit à le voir.
La certification Professional Cloud DevOps Engineer, valable deux ans, met l'accent sur les pratiques SRE : SLO, budget d'erreur, observabilité. L'entretien vérifie que le candidat sait passer d'un objectif de disponibilité à une alerte utile dans Cloud Monitoring, et qu'il a déjà remplacé des clés de compte de service par une fédération d'identité. Le PDF contient 30 questions et un cas de 20 minutes.
Google Cloud vu par l'ingénieur DevOps
Organisation, dossiers et projets
Sur GCP, tout est rangé dans une hiérarchie : l'organisation, des dossiers, puis des projets qui contiennent les ressources. Les droits et les contraintes posés en haut descendent sur tout ce qui est en dessous. Le découpage en projets décide de l'isolation et de la lecture de la facture.
IAM, comptes de service et Workload Identity Federation
IAM attribue des rôles à des personnes, des groupes et des comptes de service. Workload Identity Federation for GKE donne des droits à un pod GKE, Workload Identity Federation à un pipeline GitHub ou GitLab, tous deux sans clé JSON. Les clés de compte de service sont la source d'incident la plus fréquente, à faire disparaître.
GKE (Autopilot et Standard)
Le Kubernetes managé de Google. En Autopilot, Google gère les nœuds et la facture suit les ressources des pods. En Standard, l'équipe gère ses node pools. Les sujets à creuser : canaux de version, plages d'adresses, exposition par Gateway API.
Cloud Run et Cloud Run functions
Cloud Run exécute des conteneurs sans cluster, avec une mise à l'échelle jusqu'à zéro. Cloud Run functions est le nouveau nom de Cloud Functions. Pour beaucoup d'API, Cloud Run évite d'opérer GKE, et un bon profil sait dire où passe la limite.
VPC partagé, Cloud NAT et load balancers
Le VPC est global, découpé en subnets régionaux, et souvent partagé : un projet hôte porte le réseau, les projets de service l'utilisent. Cloud NAT donne une sortie Internet aux machines privées. Les load balancers globaux exposent les services HTTP(S).
Cloud Build, Artifact Registry et Cloud Deploy
Cloud Build exécute les builds, Artifact Registry stocke images et paquets, Cloud Deploy promeut une version de la recette à la production. Container Registry (gcr.io) est fermé depuis mars 2025, mais l'adresse gcr.io peut encore pointer vers Artifact Registry. Beaucoup d'équipes gardent GitLab CI ou GitHub Actions et n'utilisent que le registre.
Terraform (provider google)
L'outil d'infrastructure le plus cité dans les offres GCP, parfois avec Terragrunt. Le state est stocké dans un bucket Cloud Storage, verrouillé nativement. Une fabrique de projets en Terraform crée chaque nouveau projet avec ses droits, ses API et son budget.
Cloud Logging, Cloud Monitoring et SLO
Cloud Logging centralise les journaux, Cloud Monitoring les métriques, les alertes et les SLO, et Managed Service for Prometheus collecte les métriques de GKE. La culture SRE de Google y est très présente, avec des alertes sur le budget d'erreur.
Les équipes qui recrutent sur GCP font souvent tourner des microservices sur GKE, parfois avec OpenShift à côté, ou des services plus légers sur Cloud Run. L'ingénieur DevOps GCP gère alors les projets et leurs droits, le VPC partagé, les clusters, les pipelines et la supervision. Terraform reste l'outil d'infrastructure le plus cité, avec Terragrunt dans certaines équipes. Cloud Build et Cloud Deploy apparaissent moins dans les offres que GitLab CI ou GitHub Actions, mais la question d'identité reste la même : un pipeline externe doit obtenir ses droits sur GCP sans clé de compte de service. L'offre indique GKE Autopilot ou Standard, et la forge utilisée.
Les compétences GCP à vérifier en entretien
- Hiérarchie de ressources et héritage IAM
- Identités sans clé et Workload Identity Federation
- GKE, Cloud Run et choix d'exécution
- VPC partagé, Cloud NAT et adressage
- Cloud Build, Artifact Registry et Terraform
- SLO et observabilité dans Cloud Monitoring
Questions pour un ingénieur DevOps GCP, réponses attendues comprises
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un développeur a le rôle Éditeur sur le dossier qui contient tous les projets de production. Qu'est-ce que cela implique, et que proposez-vous ?
Une bonne réponseLe rôle s'hérite : il vaut sur chaque projet du dossier, présent et futur, et une allow policy posée au niveau d'un projet ne peut pas le retirer. Seule une deny policy IAM le peut. Éditeur est un rôle de base, très large, qui permet de modifier presque toutes les ressources. La correction : des rôles prédéfinis attribués par projet à des groupes plutôt qu'à des personnes, l'IAM Recommender pour réduire les droits inutilisés, et Privileged Access Manager pour les accès temporaires à la production.
Signal d'alerte« Je retire le rôle sur le projet critique », sans savoir que l'héritage l'empêche. Garder Éditeur « pour la souplesse ».
Question 2 · confirmé
Une nouvelle API sans état reçoit un trafic irrégulier, et l'équipe ne connaît pas Kubernetes. Cloud Run ou GKE ?
Une bonne réponseCloud Run, sauf contrainte particulière : pas de cluster à opérer, mise à l'échelle jusqu'à zéro, facturation à l'usage. Le candidat connaît les réglages qui comptent : nombre minimal d'instances contre le démarrage à froid, concurrence par instance, durée maximale de requête (jusqu'à 60 minutes), sortie vers le VPC pour joindre une base privée. GKE se justifie avec beaucoup de services, des besoins propres à Kubernetes (opérateurs, charges avec état, maillage de services) ou une charge stable où le coût par vCPU devient meilleur.
Signal d'alerte« GKE, c'est plus professionnel. » Ou Cloud Run présenté comme gratuit, sans parler du coût sous une charge constante.
Question 3 · confirmé
Sur GKE, un pod doit publier dans un topic Pub/Sub. Comment lui donnez-vous ce droit sans clé, et sans le donner aux autres pods ?
Une bonne réponseAvec Workload Identity Federation for GKE, toujours active sur Autopilot et à activer sur Standard. Le pool d'identités du projet s'appelle PROJECT_ID.svc.id.goog. On accorde roles/pubsub.publisher sur le topic seul, directement au principal qui représente le service account Kubernetes (namespace et nom), ou on lie ce service account à un compte de service IAM par impersonation. Le compte de service des nœuds garde des droits minimaux.
Signal d'alerteUne clé JSON dans un Secret Kubernetes. Le rôle donné au compte de service Compute Engine par défaut des nœuds, donc à tous les pods.
Question 4 · confirmé
Les pods d'un cluster GKE privé n'arrivent pas à joindre une API externe, alors que les API Google répondent. Que vérifiez-vous ?
Une bonne réponseLes nœuds n'ont pas d'adresse externe : il faut Cloud NAT sur un Cloud Router dans la région du subnet. L'accès privé à Google explique pourquoi les API Google répondent quand même. Ensuite, les règles de pare-feu en sortie du VPC, les network policies du cluster, et l'épuisement des ports NAT visible dans les journaux de Cloud NAT. En VPC partagé, NAT et pare-feu se gèrent dans le projet hôte, donc avec l'équipe réseau.
Signal d'alerteDonner une adresse publique aux nœuds, ou ouvrir le pare-feu à 0.0.0.0/0 en entrée.
Question 5 · confirmé
Une image construite par Cloud Build doit passer de la recette à la production sans être reconstruite. Comment organisez-vous cela ?
Une bonne réponseUn seul build, une image poussée dans Artifact Registry et déployée par son digest, jamais par un tag latest. La promotion passe par Cloud Deploy (pipeline de livraison, cibles recette et production, approbation, retour arrière) ou par GitOps. Binary Authorization n'admet en production que les images attestées par le build. Artifact Analysis signale les vulnérabilités. Chaque environnement a son propre compte de service de déploiement. Le candidat sait que Container Registry (gcr.io) est fermé depuis mars 2025.
Signal d'alerteUne reconstruction par environnement, un tag latest, ou le compte de service Cloud Build avec le rôle Éditeur.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Ingénieur DevOps GCP : questions fréquentes
Que vérifier en priorité chez un ingénieur DevOps Google Cloud ?
Trois sujets suffisent à situer un profil. L'IAM : comprendre l'héritage des rôles sur les dossiers et les projets, et savoir travailler sans clé de compte de service. Le réseau : VPC partagé, Cloud NAT, plages d'adresses de GKE. La plateforme d'exécution : opérer GKE et savoir quand Cloud Run suffit. Kubernetes, Terraform et la CI/CD restent le socle, comme sur les autres clouds.
Que vaut la certification Professional Cloud DevOps Engineer ?
Elle couvre l'organisation Google Cloud, les pratiques SRE, la CI/CD, l'observabilité et l'optimisation des coûts. Google recommande trois ans d'expérience, dont un sur GCP en production, et elle reste valable deux ans. Elle indique une bonne connaissance des services et de la culture SRE. L'examen est un QCM : il ne montre pas comment la personne a géré un incident ou une migration. Un exemple concret le montre.
Faut-il exiger GKE ou Cloud Run dans l'offre ?
Seul compte ce que l'équipe utilise vraiment. Un poste centré sur GKE demande une expérience de Kubernetes en production : mises à jour, réseau, droits des pods. Un poste centré sur Cloud Run demande surtout IAM, réseau et CI/CD, et un profil sans grande expérience de Kubernetes peut convenir. Si les deux coexistent, l'offre indique la proportion pour attirer les bons candidats.
Comment organiser le test technique d'un ingénieur DevOps GCP ?
Un diagnostic de trente minutes pendant l'entretien. L'exercice part d'un extrait de politique IAM avec un rôle Éditeur sur un dossier et une clé de compte de service dans un pipeline : la personne dit ce qu'elle change. Autre option : un pod GKE qui ne joint pas une API externe. Le raisonnement à voix haute montre l'expérience. La grille note la méthode autant que la solution trouvée.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
