2.2 - Infrastructure as Code (IaC)
L'objectif 2.2 du Cloud+ CV0-004 couvre l'Infrastructure as Code (IaC), qui définit l'infrastructure dans des fichiers modèles déclaratifs pour des constructions reproductibles et versionnées. Un modèle déclaratif énonce l'état final voulu et l'outil détermine comment l'atteindre, contrairement à un script impératif qui liste chaque étape. Tu regroupes de l'IaC réutilisable dans une unité paramétrée que d'autres modèles peuvent appeler : c'est un module. L'IaC façonne aussi la gestion des serveurs : l'infrastructure mutable modifie et patche les serveurs vivants au fil du temps, tandis que l'infrastructure immuable remplace les serveurs par de nouvelles images plutôt que de les modifier, évitant la dérive. Tu dois aussi connaître les fichiers d'état, l'idempotence et des outils comme Terraform et CloudFormation. Attends-toi à des mises en situation demandant le bon concept IaC - déclaratif, module, mutable ou immuable.
Infra définie dans des modèles versionnés = IaC. Énonce l'état final, l'outil trouve comment = déclaratif. Unité IaC réutilisable paramétrée = module. Patcher les serveurs vivants = mutable ; remplacer par de nouvelles images = immuable.
Questions d'entraînement
1. Définir l'infrastructure dans des fichiers de gabarits déclaratifs pour des déploiements reproductibles et versionnés s'appelle :
- Mise à l'échelle automatique
- Infrastructure as Code (bonne réponse)
- Répartition de charge réseau
- Instantané de volume
L'Infrastructure as Code (IaC) provisionne des ressources à partir de gabarits versionnés (Terraform, CloudFormation), rendant les déploiements reproductibles et auditables.
2. Au lieu de corriger un serveur en marche, l'équipe le reconstruit depuis une image à chaque changement. Cette approche est :
- Infrastructure immuable (bonne réponse)
- Infrastructure mutable
- Configuration manuelle
- Correctif sur place
L'infrastructure immuable ne modifie jamais un serveur vif ; chaque changement produit une image neuve qui remplace l'ancienne instance. Cela supprime la dérive et facilite le retour arrière.
3. Un blueprint provisionne une base avant l'application qui la lit. Que doit respecter l'outil pour réussir ?
- Affinité de région
- Ordre des dépendances (bonne réponse)
- Session collante
- Étiquetage des coûts
L'ordre des dépendances garantit que les ressources se construisent dans la bonne séquence : la base existe avant l'application qui la référence. Les outils IaC le déduisent d'un graphe de dépendances.
4. Un script de provisionnement impératif diffère d'un déclaratif car il :
- Liste les étapes exactes à exécuter (bonne réponse)
- N'énonce que l'objectif final
- Ne peut pas être stocké dans Git
- N'utilise jamais de variables
Le code impératif précise chaque étape dans l'ordre pour atteindre un état ; le code déclaratif décrit l'état final voulu et laisse l'outil trouver les étapes. Les deux peuvent vivre dans Git.
5. Amener votre licence logicielle existante pour l'exécuter sur des instances cloud au lieu d'en louer une, c'est :
- Paiement à l'usage
- BYOL (bonne réponse)
- Open source
- Usage compté
Le BYOL (Bring Your Own License) permet de réutiliser des licences déjà possédées sur des instances cloud, souvent moins cher. Le paiement à l'usage inclut la licence dans le tarif horaire.
6. Un avantage clé de stocker les gabarits IaC dans un gestionnaire de versions est de pouvoir :
- Éviter tout test automatisé
- Réviser et annuler les changements (bonne réponse)
- Éviter d'écrire toute documentation
- Contourner tout contrôle d'accès
L'IaC versionnée offre revue par les pairs, historique et retour arrière des changements d'infrastructure, la traitant comme du code applicatif. Elle ne supprime pas le besoin de tests ni de contrôle d'accès.