Amazon DOP-C02: Infrastructure en tant que code et gestion de la configuration — Guide d'étude

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fait partie du AWS DevOps Engineer Professional DOP-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

L’Infrastructure as Code (IaC) et la gestion de configuration sur AWS permettent un provisionnement et une configuration reproductibles, auditables et gouvernés de l’infrastructure et des applications. CloudFormation et l’AWS Cloud Development Kit (CDK) décrivent les ressources de manière déclarative ou via du code qui est synthétisé en CloudFormation. Des couches de configuration telles qu’AWS OpsWorks et AWS Systems Manager appliquent et rapportent l’état désiré sur les instances à travers les parcs EC2 et hybrides. Les secrets, les paramètres et la création d’images (image-baking) complètent le cycle de vie, permettant des déploiements immuables et sécurisés à grande échelle.

Piles CloudFormation, contrôle des changements et gouvernance

Les piles (stacks) CloudFormation sont l’unité de déploiement. Concevez les piles en fonction des limites de cycle de vie et de la propriété pour minimiser le rayon d’impact (blast radius). Utilisez les paramètres avec parcimonie et préférez des valeurs par défaut bien définies (opinionated defaults) avec des mappages ou des recherches SSM. Exportez et importez uniquement des valeurs stables et partagées via les Outputs et Fn::ImportValue pour éviter un couplage fort.

Les piles imbriquées (nested stacks) encapsulent des composants réutilisables et permettent de conserver des modèles parents de petite taille. Une pile parente peut passer des paramètres aux piles enfants et consommer leurs sorties, permettant des architectures modulaires (par exemple, une pile imbriquée de réseau partagé consommée par une pile applicative). Maintenez les piles imbriquées focalisées sur une seule responsabilité (VPC, couche de données, couche applicative) et versionnez-les indépendamment.

Les StackSets déploient un modèle unique sur plusieurs comptes et Régions. Utilisez le modèle de permissions géré par le service avec AWS Organizations pour déployer automatiquement sur les UO (OUs) et inclure automatiquement les nouveaux comptes. Configurez les préférences d’opération (nombre maximum de comptes/Régions simultanés, tolérance aux pannes) pour contrôler le déploiement. Les substitutions de paramètres (parameter overrides) par compte ou par Région vous permettent d’adapter un modèle standard aux contraintes locales. Surveillez la dérive (drift) des StackSets et des instances de pile pour détecter les changements hors bande.

Les jeux de modifications (change sets) permettent des mises à jour sûres et vérifiables par un humain. Utilisez toujours CreateChangeSet et inspectez l’impact ressource par ressource, les remplacements et les pertes de données potentielles avant d’exécuter ExecuteChangeSet. Intégrez les jeux de modifications dans des pipelines automatisés pour des approbations contrôlées (gated approvals).

La détection de dérive (drift detection) valide que les ressources de la pile correspondent au modèle. Exécutez régulièrement la détection de dérive sur les piles et StackSets critiques ; comprenez que toutes les propriétés ne sont pas évaluées pour tous les types de ressources (les propriétés non prises en charge sont signalées comme « non vérifiées »). Traitez la dérive comme un incident : investiguez, capturez le contexte et corrigez soit par une mise à jour de la pile, soit en codifiant la dérive et en la réappliquant.

Les politiques de pile (stack policies) sont des documents JSON qui protègent les ressources critiques lors des mises à jour. Refusez les mises à jour sur les ressources irremplaçables (par exemple, les bases de données de production, les zones Route 53) et utilisez StackPolicyDuringUpdateBody pour ouvrir temporairement une voie chirurgicale pour un changement spécifique, puis restaurez la politique plus stricte. Combinez avec la protection contre la terminaison et la DeletionPolicy (Retain/Snapshot) pour mettre en place des garde-fous (guardrails). Pour les ressources avec un état externe (buckets S3), planifiez les comportements de suppression. Si un bucket doit être vidé avant sa suppression, implémentez une ressource personnalisée pour purger les objets lors de la suppression de la pile.

AWS CDK et extensibilité de CloudFormation

L’AWS CDK modélise l’infrastructure dans des langages familiers (TypeScript, Python, Java, .NET, Go). Les Constructs sont les blocs de construction du CDK :

Les constructs L1 (CfnXxx) sont générés à partir de la spécification CloudFormation et correspondent un-à-un aux ressources.
Les constructs L2 ajoutent une intention de haut niveau et des valeurs par défaut sensées (par exemple, ApplicationLoadBalancedFargateService).
Les « patterns » L3 composent plusieurs L2 pour des architectures prêtes à l’emploi.

Une application CDK contient une ou plusieurs piles. Pendant l’exécution de cdk synth, l’application résout les recherches de contexte (par exemple, les ID de VPC), génère les assets et produit un modèle CloudFormation. Avant de déployer, cdk bootstrap crée les buckets d’assets et les rôles de l’environnement. Utilisez cdk diff pour prévisualiser les changements, puis cdk deploy pour soumettre les modèles et les assets ; le CDK utilise en interne les jeux de modifications et affichera et confirmera les changements sensibles à la sécurité (IAM ou remplacements de ressources). Taguez les piles et les ressources via les Aspects pour appliquer une politique de taggage à l’échelle de l’organisation. Lorsque les abstractions L2 sont insuffisantes, utilisez les échappatoires (escape hatches) (node.defaultChild) ou revenez aux constructs L1.

Les ressources personnalisées (custom resources) de CloudFormation étendent l’IaC à tout ce qui est accessible via des API. Une ressource personnalisée basée sur Lambda reçoit des événements Create, Update et Delete avec un RequestId, un PhysicalResourceId et des propriétés. La fonction doit :

Être idempotente et renvoyer un succès/échec à l’URL présignée (ResponseURL) dans le délai imparti (timeout).
Définir un PhysicalResourceId stable pour suivre les mises à jour et piloter le nettoyage lors d’un Delete.
Gérer les nouvelles tentatives (retries) et les attentes de stabilisation pour les services en aval à cohérence éventuelle (eventually consistent).

Utilisez des rôles d’exécution IAM de moindre privilège pour la Lambda, incluez un backoff exponentiel sur les appels d’API, et corrélez les logs via le RequestId. Pour les opérations volumineuses ou de longue durée, envisagez d’utiliser Step Functions avec une ressource personnalisée qui attend un jeton d’exécution. Préférez le CloudFormation Registry pour des fournisseurs (providers) réutilisables et versionnés lorsque cela est applicable.

Secrets et paramètres dans l’Infrastructure as Code

Ne codez jamais de secrets en dur dans les modèles ou le code. Utilisez des références dynamiques pour résoudre les valeurs sensibles au moment du déploiement :

Secrets Manager : {{resolve:secretsmanager:secret-id:SecretString:json-key:version-stage}}
SecureString Parameter Store : {{resolve:ssm-secure:parameter-name:version}}

Les références dynamiques empêchent le stockage des secrets dans le modèle de pile ou les événements. Ne placez pas de secrets dans les Outputs ou les propriétés de ressources que CloudFormation journalise en texte clair. Accordez au rôle d’exécution de CloudFormation la permission de déchiffrer ou de récupérer les valeurs référencées, et limitez la portée des KMS CMK aux principaux qui ont besoin d’y accéder.

Parameter Store est idéal pour la configuration non secrète (indicateurs de fonctionnalités, ID d’AMI, points de terminaison). Utilisez des paramètres SSM versionnés pour créer des restaurations (rollbacks) sécurisées et des promotions atomiques entre les environnements. Dans le CDK, importez les valeurs avec ssm.StringParameter.fromStringParameterName ou fromSecureStringParameterAttributes pour les valeurs sécurisées, et intégrez les lectures de paramètres dans les user data ou les bootstraps d’application.

Secrets Manager est conçu pour les contrôles de cycle de vie, la rotation et l’audit. Intégrez la rotation avec les moteurs pris en charge (RDS, Aurora) ou des Lambdas personnalisées. Référencez les secrets au moment de l’exécution (runtime) plutôt que de les intégrer (baking) dans les AMI pour éviter la prolifération de matériel obsolète. Pour les charges de travail conteneurisées ou serverless, injectez les secrets via des variables d’environnement soutenues par des références Secrets Manager ou montez-les via les secrets ECS/TaskDefinition ; effectuez la rotation avec un temps d’arrêt minimal en utilisant des pools de connexions à court TTL et des tentatives (retries).

Gestion de la Configuration et Infrastructure Immuable

AWS OpsWorks fournit une gestion de configuration prescriptive. OpsWorks Stacks utilise des cookbooks Chef et des événements de cycle de vie (Setup, Configure, Deploy, Undeploy, Shutdown) pour orchestrer la configuration et les déploiements d’applications, et prend en charge l’auto-réparation avec des bilans de santé qui arrêtent/démarrent ou remplacent les instances. Historiquement, OpsWorks proposait également des services gérés Chef Automate et Puppet Enterprise ; aujourd’hui, de nombreuses équipes se standardisent sur Systems Manager pour l’orchestration basée sur des agents ou gèrent elles-mêmes des plans de contrôle Ansible/Chef/Puppet. Ansible n’est pas intégré nativement avec OpsWorks ; à la place, utilisez Systems Manager State Manager pour exécuter des playbooks, ou AWX/Ansible Automation Platform avec la connectivité SSM Session Manager et l’inventaire dynamique EC2.

AWS Systems Manager est le plan de contrôle moderne pour la configuration hybride :

State Manager applique un état désiré via des Associations qui exécutent des documents SSM (YAML/JSON) selon un calendrier, un événement ou au démarrage d’une instance. Utilisez

undefined

et des documents personnalisés pour faire converger la configuration. Paramétrez les associations et ciblez par tags pour des changements à l’échelle du parc.

La conformité de la configuration expose l’état des associations et les résultats de Patch Manager. Utilisez des référentiels de correctifs (patch baselines) pour définir les classifications approuvées, les lier à des fenêtres de maintenance (Maintenance Windows) et suivre la conformité par tag d’instance, groupe de correctifs ou groupe de ressources. Les Hybrid Activations intègrent les nœuds sur site en tant qu’instances gérées pour une gouvernance uniforme.
Inventory enregistre les paquets, les fichiers et les mises à jour Windows ; Resource Data Sync exporte vers S3 et Athena pour le reporting d’entreprise. Combinez la conformité SSM avec les règles AWS Config et la remédiation automatique (runbooks Systems Manager Automation) pour boucler la boucle de la détection à la correction.

L’infrastructure immuable élimine la dérive et accélère les retours en arrière (rollbacks). EC2 Image Builder codifie les pipelines d’images avec :

Des composants (étapes d’installation, de durcissement, de validation) exprimés sous forme de documents.
Des recettes d’images (Image recipes) qui assemblent des composants et des images de base.
Des configurations d’infrastructure définissant les subnets, les groupes de sécurité, les profils d’instance et la journalisation.
Des configurations de distribution pour répliquer les AMIs dans les Régions et les partager avec d’autres comptes.

Ajoutez des composants de test pour valider les référentiels CIS, la santé des agents (SSM/CloudWatch) et les tests de fumée applicatifs. Versionnez les images et étiquetez-les avec des tags sémantiques. Publiez les ID d’AMI dans Parameter Store (par exemple, /app/frontend/ami) et référencez-les dans les modèles de lancement Auto Scaling. Déployez avec des stratégies de type rolling ou blue/green ; remplacez les instances au lieu d’appliquer des correctifs sur place pour préserver l’immuabilité. Intégrez les analyses de vulnérabilités (Amazon Inspector) dans les portes de promotion du pipeline. N’intégrez pas de secrets dans les images ; récupérez-les au démarrage via l’Instance Metadata Service v2 et des références SSM/Secrets Manager.

Scénario de Problème Pratique

Capital One doit standardiser les déploiements multi-comptes et multi-régions pour une plateforme destinée aux clients, tout en appliquant une gouvernance stricte, une gestion des secrets rigoureuse et en éliminant la dérive de configuration. L’environnement s’étend sur des centaines de comptes dans AWS Organizations, avec des contrôles stricts sur l’accès aux bases de données et le durcissement des systèmes d’exploitation.

Modéliser l’infrastructure avec AWS CDK et la synthétiser en CloudFormation

Implémenter des constructions L2/L3 pour les VPCs, ALBs, groupes Auto Scaling et Aurora. Utiliser cdk synth et cdk diff dans la CI pour générer et valider les modèles et les change sets.
Pourquoi CDK : Composition et réutilisation fortes grâce aux constructions, politiques programmatiques via les Aspects pour le tagging et les garde-fous à l’échelle de l’organisation, et intégration native avec CloudFormation pour l’auditabilité.

Distribuer les piles de réseau de base et de garde-fous via CloudFormation StackSets

Créer des StackSets gérés par le service (service-managed) ciblant les OUs de sécurité et de bac à sable (sandbox) pour déployer des points de terminaison VPC partagés, des alarmes CloudWatch standard et des périmètres IAM. Activer le déploiement automatique sur les nouveaux comptes avec une tolérance aux pannes et des contrôles de simultanéité.
Pourquoi StackSets : Déploiement cohérent à l’échelle de l’organisation avec inclusion automatique des nouveaux comptes et détection de dérive intégrée.

Protéger les ressources critiques avec des politiques de pile et des change sets

Appliquer des politiques de pile (stack policies) qui refusent les mises à jour des clusters Aurora et des zones Route 53. Exiger CreateChangeSet et une approbation manuelle avant ExecuteChangeSet dans le pipeline pour la production.
Pourquoi les politiques de pile/change sets : Appliquer des mutations de moindre privilège et fournir une revue humaine avant les changements à haut risque.

Étendre l’IaC avec des ressources personnalisées (custom resources) basées sur Lambda

Implémenter une ressource Custom::S3BucketCleanup pour vider les buckets applicatifs lors de la suppression de la pile et une Custom::AuroraParameterTuner qui applique les paramètres du moteur après la création.
Pourquoi les ressources personnalisées : Combler les lacunes fonctionnelles du provisionnement déclaratif tout en gardant le cycle de vie lié à la pile.

Centraliser les secrets et la configuration avec Secrets Manager et Parameter Store

Stocker les identifiants de base de données et les clés d’API dans Secrets Manager avec des Lambdas de rotation ; publier les ID d’AMI, les feature flags et les points de terminaison dans Parameter Store. Référencer les valeurs via des références dynamiques dans CloudFormation et des imports CDK à l’exécution pour les applications.
Pourquoi ces services : Séparation des préoccupations — les secrets avec rotation et audit, les paramètres pour la configuration non secrète et une promotion facile.

Appliquer l’état désiré et la conformité via Systems Manager State Manager

Créer des associations pour installer des agents, configurer les paramètres de l’OS et appliquer des playbooks Ansible si nécessaire. Utiliser Patch Manager avec des fenêtres de maintenance (Maintenance Windows) pour l’application de correctifs en dehors des heures de bureau et des tableaux de bord de conformité agrégés par Resource Data Sync.
Pourquoi State Manager : Convergence basée sur un agent à travers EC2 et sur site avec un reporting de conformité continu et une remédiation à l’échelle.

Adopter une infrastructure immuable avec EC2 Image Builder

Construire des AMIs durcies avec des composants pour les référentiels CIS, les agents SSM/Inspector et les dépendances d’exécution de l’application. Exécuter des tests, publier les ID d’AMI dans Parameter Store et lier les modèles de lancement Auto Scaling aux paramètres versionnés. Déployer via des mises à jour progressives (rolling updates) ; déclencher une actualisation d’instance (instance refresh) lors des mises à jour d’AMI.
Pourquoi Image Builder : Des images reproductibles et testables qui éliminent la dérive et réduisent le temps moyen de rétablissement (MTTR) grâce à des rollbacks rapides.

Orchestration et gouvernance du pipeline

Implémenter un pipeline à plusieurs étapes qui exécute cdk synth/diff, crée des change sets, se met en pause pour approbation, puis exécute. Utiliser EventBridge pour déclencher les mises à jour de StackSet sur les changements de dépôt. Ajouter des analyses de détection de dérive nocturnes et ouvrir des éléments OpsCenter pour les divergences.
Pourquoi cette approche : Livraison continue avec des promotions auditables, détection proactive de la dérive et remédiation automatisée grâce à des responsabilités de service bien définies.

← Pipelines CI · Tous les domaines · Surveillance →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →