Les offres qui citent Pulumi sont moins nombreuses que celles qui citent Terraform, et Pulumi y figure souvent à côté de Kubernetes, Helm, GitHub Actions et d'un cloud public. Un ingénieur Pulumi écrit des programmes qui créent les ressources cloud, les regroupe en composants réutilisables et les déploie par stack, une stack par environnement. Le langage suit en général celui de l'équipe de développement, TypeScript et Python en tête.
Le risque vient des deux côtés. Un développeur à l'aise en TypeScript peut écrire un programme Pulumi qui compile et ignorer tout du cycle de vie des ressources. Un profil Terraform peut traduire son HCL ligne à ligne sans profiter du langage ni écrire un test. Les Outputs, ces valeurs connues seulement après le déploiement, montrent vite le niveau réel.
En entretien, la personne lit un court programme qui construit une chaîne de connexion à partir d'un Output et dit ce qu'il produit. Les secrets de stack et les tests avec mocks font aussi partie de l'entretien. Le PDF propose 30 questions réparties sur six axes, un cas de 20 minutes et une grille de 1 à 4.
Pulumi et son écosystème, brique par brique
Pulumi IaC et ses langages
Le moteur open source de Pulumi lit un programme écrit en TypeScript, Python, Go, C#, Java ou YAML, calcule les différences avec l'existant et les applique avec pulumi preview puis pulumi up. Les providers couvrent AWS, Azure, GCP, Kubernetes et des centaines de services, dont une partie est générée à partir des providers Terraform.
Stacks et configuration
Une stack est une instance du programme, en pratique un environnement : dev, recette, production. Chacune a sa configuration dans un fichier Pulumi.<stack>.yaml et son propre state. Les valeurs sensibles y sont chiffrées avec pulumi config set --secret. Une stack peut lire les outputs d'une autre par une StackReference.
Outputs, apply et interpolate
Les attributs d'une ressource, comme l'adresse d'une base, ne sont connus qu'après sa création. Pulumi les représente par des Outputs, qu'on combine avec apply, all ou interpolate. C'est la notion qui pose le plus de difficultés aux développeurs qui débutent avec Pulumi.
Component resources
Le moyen de regrouper plusieurs ressources dans un composant réutilisable, par exemple un service web avec son équilibreur de charge, ses droits et ses journaux. Publié en package Pulumi, un composant écrit en TypeScript peut être utilisé depuis Python ou Go.
Pulumi Cloud ou backend autogéré
Le state peut vivre dans Pulumi Cloud, le service géré qui ajoute l'historique, les droits par équipe et l'audit, ou dans un bucket S3, Azure Blob ou GCS. Avec un backend autogéré, l'équipe choisit son secrets provider : passphrase, AWS KMS, Azure Key Vault, Google Cloud KMS ou Vault.
Pulumi ESC
Le service de Pulumi pour les environnements, les secrets et la configuration partagés. Il lit des secrets dans Vault, AWS Secrets Manager, Azure Key Vault ou 1Password et fournit des identifiants cloud de courte durée par OIDC. Les stacks importent ces environnements dans leur configuration.
Automation API
Une bibliothèque qui pilote Pulumi depuis un programme, sans passer par la CLI. Les équipes plateforme s'en servent pour créer des environnements à la demande, des portails internes ou des tests d'intégration. Reste à savoir comment la personne gère les erreurs et les demandes simultanées.
Pulumi Policies et tests
Pulumi Policies, anciennement CrossGuard, applique des règles écrites en TypeScript, en Python ou en OPA à chaque preview, avec des niveaux advisory, mandatory ou remediate. Les tests unitaires remplacent le moteur par des mocks et tournent en quelques secondes. Les tests d'intégration déploient pour de vrai dans un compte de test.
Les postes Pulumi se trouvent souvent dans des équipes où les développeurs gèrent eux-mêmes leur infrastructure, ou dans des équipes plateforme qui construisent un self-service avec l'Automation API. On croise aussi des missions de migration depuis Terraform, avec pulumi convert et l'import des ressources existantes. Le titre de l'offre dit rarement « ingénieur Pulumi » : on lit ingénieur DevOps, platform engineer ou SRE, avec Pulumi dans la liste des outils. Comme pour tout outil d'infrastructure as code, la connaissance d'un cloud en profondeur reste indispensable. Un programme Pulumi bien écrit ne corrige pas un réseau mal conçu.
Ce qu'un ingénieur Pulumi doit maîtriser
- Modèle de programmation : Outputs et dépendances
- Stacks, configuration et secrets
- Component resources et packages
- Tests unitaires, politiques et intégration
- Cycle de vie : aliases, import, refresh
- Automation API et pipeline de déploiement
Cinq questions d'entretien et les réponses attendues
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é
Dans un programme TypeScript, la chaîne de connexion construite avec un gabarit autour de db.endpoint contient un message d'avertissement au lieu de l'adresse de la base. Pourquoi, et comment corrigez-vous ?
Une bonne réponsedb.endpoint est un Output, une valeur qui n'existe qu'une fois la base créée. Le gabarit de chaîne appelle toString sur l'objet et Pulumi renvoie un avertissement à la place de la valeur. Il écrit pulumi.interpolate`postgres://${db.endpoint}/app` ou db.endpoint.apply(e => ...). Le résultat reste un Output, qu'il passe tel quel en entrée d'une autre ressource pour garder la dépendance. Un bon profil ajoute qu'on ne crée pas de ressource à l'intérieur d'un apply, car le preview ne peut pas la montrer.
Signal d'alerteUn await sur l'Output, un JSON.stringify, ou une variable globale remplie dans un apply « pour s'en servir plus tard ».
Question 2 · confirmé
Vous renommez une ressource dans le code, ou vous la déplacez dans un composant. Que fait pulumi up, et comment évitez-vous la recréation ?
Une bonne réponseL'URN de la ressource dépend de son nom logique, de son type et de son parent. Le changer revient, pour Pulumi, à supprimer une ressource et à en créer une autre. Il ajoute l'option aliases avec l'ancien nom ou l'ancien parent, vérifie que le preview n'affiche plus de remplacement, puis retire l'alias une fois toutes les stacks mises à jour. Sur les ressources qui portent des données, protect: true bloque toute suppression accidentelle.
Signal d'alerteLancer pulumi up « pour voir », ou ne pas savoir ce qu'est une URN.
Question 3 · confirmé
Comment gérez-vous le mot de passe d'une base de données dans une stack Pulumi ?
Une bonne réponseSoit pulumi config set --secret, chiffré par le secrets provider de la stack, soit un mot de passe généré par random.RandomPassword, soit une valeur lue dans Pulumi ESC depuis Secrets Manager ou Vault. Un Output secret reste chiffré dans le state et masqué dans les sorties, et tout ce qui en dérive l'est aussi. Il connaît pulumi.secret() et additionalSecretOutputs pour marquer une valeur que le provider ne marque pas. Avec un backend autogéré, il choisit un secrets provider KMS ou Key Vault plutôt qu'une passphrase partagée.
Signal d'alerteUn mot de passe en clair dans Pulumi.prod.yaml, ou affiché avec console.log pendant le déploiement.
Question 4 · senior
Vous écrivez une component resource « service web » réutilisée par dix équipes. Comment la concevez-vous ?
Une bonne réponseUne classe qui étend ComponentResource avec un type explicite (par exemple acme:web:Service), une interface d'arguments typée et courte, et des enfants créés avec parent: this pour qu'ils héritent des options et des providers. registerOutputs à la fin, et seuls les outputs utiles exposés. Les bons réglages sont là par défaut : chiffrement, étiquettes, journaux. Le composant est versionné et publié sur un registre npm ou PyPI interne, ou en package Pulumi s'il doit servir à plusieurs langages. Il a ses propres tests.
Signal d'alerteUne fonction qui renvoie une liste de ressources sans parent, ou un fichier recopié d'un dépôt à l'autre.
Question 5 · confirmé
Comment écrivez-vous un test unitaire qui vérifie qu'aucun bucket n'est public, sans rien déployer ?
Une bonne réponsepulumi.runtime.setMocks avant d'importer le programme, avec un newResource qui renvoie un identifiant factice et les entrées, et un call pour les fonctions de lecture. Le test lit les propriétés du bucket à travers l'Output (apply ou promesse) et vérifie l'absence d'ACL publique et la présence du blocage d'accès public. Mocha, Jest ou pytest font l'affaire. Il connaît la limite : les mocks ne valident pas le comportement du provider, d'où une politique Pulumi Policies sur le preview et un test d'intégration sur une stack éphémère.
Signal d'alerte« On regarde dans la console après le up », ou des tests qui déploient dans le compte de production.
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
Questions fréquentes sur le poste d'ingénieur Pulumi
Pour un poste Pulumi, faut-il un développeur ou un profil infrastructure ?
Le poste demande les deux. Le langage de programmation s'apprend vite pour un profil infrastructure qui code déjà en Python ou en TypeScript. L'inverse prend plus de temps : un développeur doit apprendre le réseau, IAM et le cycle de vie des ressources. La maîtrise du cloud passe d'abord, puis la qualité du code : tests, typage, découpage en composants.
Un ingénieur Terraform peut-il prendre un poste Pulumi ?
Oui, les notions de state, de plan et de provider sont les mêmes. Pulumi utilise d'ailleurs des providers dérivés de ceux de Terraform pour une partie des services. Le passage demande d'apprendre les Outputs, les stacks, les composants et les tests dans un langage généraliste. La personne doit écrire du vrai code dans le langage de l'équipe, et pas du HCL traduit mot à mot.
Quel exercice donner en test technique à un ingénieur Pulumi ?
Un petit programme Pulumi avec deux défauts : une chaîne construite à partir d'un Output, et une ressource renommée qui serait recréée. La personne lit le preview, explique le problème et le corrige, puis écrit un test unitaire avec mocks. Quarante-cinq minutes suffisent. On voit à la fois le niveau de code et la prudence face à une modification en production.
Pulumi Cloud est-il obligatoire pour utiliser Pulumi ?
Non. La CLI et le moteur sont open source, et le state peut être stocké dans un bucket S3, Azure Blob ou GCS. Pulumi Cloud ajoute l'historique, les droits par équipe, ESC, Deployments et certaines fonctions de politiques. Si l'offre précise Pulumi Cloud ou un backend autogéré, le candidat doit savoir justifier ce choix. Les contraintes de sécurité et d'exploitation diffèrent.
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.
