Amazon DVA-C02: CloudFormation et Infrastructure en tant que code (SAM, CDK) — Guide d'étude

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Fait partie du AWS Developer Associate DVA-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.

Patrons principaux et bonnes pratiques pour les templates CloudFormation

Les templates CloudFormation doivent être écrits comme des descriptions déclaratives et idempotentes des ressources, en privilégiant les stacks petites et ciblées, ainsi que les stacks imbriquées pour les architectures complexes. Utilisez la section Resources avec des ID logiques explicites, et préférez les fonctions intrinsèques telles que !Ref, !GetAtt, !Sub, Fn::FindInMap, et Fn::If pour la composition et la réutilisation. Validez les templates avec aws cloudformation validate-template ou les équivalents SAM/CDK (sam validate, cdk synth) avant de créer des ensembles de modifications (change sets). Utilisez les ChangeSets (CreateChangeSet / ExecuteChangeSet) pour la revue et pour éviter les remplacements inattendus ; utilisez DescribeChangeSet pour inspecter les actions que la stack effectuera. Maintenez le corps du template sous les limites de CloudFormation en déplaçant le code inline volumineux vers S3 et en le référençant (CodeUri, S3Bucket/S3Key), ou divisez-le en stacks imbriquées avec AWS::CloudFormation::Stack. Appliquez la détection de dérive (drift detection) régulièrement en utilisant DetectStackDrift et DescribeStackResourceDrifts. Utilisez DeletionPolicy et UpdateReplacePolicy pour protéger les ressources contenant des données, et activez la protection contre la terminaison (termination protection) sur les stacks critiques. Intégrez cfn-lint et cfn-guard dans la CI/CD pour détecter tôt les problèmes structurels et les violations de politique. Pour une itération rapide, tirez parti des ChangeSets et des stratégies de mise à jour au niveau des ressources pour minimiser le rayon d’impact (blast radius) ; pour les fonctions Lambda, utilisez des déploiements versionnés pour rendre les mises à jour sûres et réversibles.

Paramétrage, mappings, secrets et données sensibles

Paramétrez les différences d’environnement avec les Parameters et Mappings de CloudFormation, en utilisant AllowedValues et ConstraintDescription pour échouer rapidement (fail fast). Évitez d’intégrer des secrets ou des identifiants en texte clair dans les Parameters ; utilisez plutôt SecureString de SSM Parameter Store ou Secrets Manager et référencez-les via des références dynamiques comme {{resolve:secretsmanager:mysecret:SecretString:password}} ou utilisez les types AWS::SSM::Parameter::Value<String>. Marquez les paramètres sensibles avec NoEcho: true pour masquer les valeurs dans la console, mais sachez que NoEcho ne chiffre pas au repos — utilisez Secrets Manager pour l’audit et la rotation. Utilisez les Mappings et Fn::FindInMap pour les valeurs déterministes et spécifiques à l’environnement (ID d’AMI par région) et Fn::GetAZs pour le calcul des zones de disponibilité. Pour les références de ressources entre des stacks dans la même région/compte, exportez les sorties (outputs) et importez-les via Fn::ImportValue ; souvenez-vous que les importations ne peuvent pas traverser les comptes ou les régions. Protégez les principaux IAM utilisés par CloudFormation en définissant la portée des rôles avec le moindre privilège ; préférez les permissions gérées par le service pour les StackSets ou provisionnez explicitement un rôle d’administration avec une portée limitée. Lorsque vous passez des variables d’environnement à des conteneurs ou à Lambda, préférez référencer les ARN de Secrets Manager ou de SSM Parameter et utilisez la récupération au moment de l’exécution (runtime) dans le code, ou utilisez les fonctionnalités de SAM/CDK pour injecter des valeurs sécurisées dans l’environnement avec chiffrement via KMS.

Déploiements multi-comptes/multi-régions, patrons multi-comptes pour CDK et SAM

Les déploiements multi-comptes et multi-régions nécessitent une orchestration allant au-delà des exportations d’une seule stack. Pour les déploiements multi-comptes/multi-régions, choisissez CloudFormation StackSets (CreateStackSet, CreateStackInstances) avec des permissions gérées par le service pour Organizations ou auto-gérées avec un rôle d’exécution dans les comptes cibles. Pour les artefacts de code applicatif, utilisez des buckets S3 centralisés avec réplication inter-comptes ou des politiques de bucket, ou laissez les outils publier les assets par région : CDK utilise des stacks de bootstrap et des assets publiés via cdk-assets et nécessite cdk bootstrap dans chaque compte/région ; CDK Pipelines (module pipelines) ou l’interface CLI aws-cdk avec --role-arn prend en charge la promotion inter-comptes. SAM utilise sam package / sam deploy qui télécharge les artefacts vers un bucket S3 ; pour le multi-compte, utilisez la CI/CD pour empaqueter et pousser les artefacts dans les buckets des comptes cibles et exécuter les déploiements avec les identifiants appropriés. Évitez les recherches de contexte CDK (VPC.fromLookup, etc.) qui nécessitent des permissions spécifiques au compte au moment de la synthèse (synth time) ; passez plutôt explicitement les identifiants en tant que paramètres pour garder la synthèse reproductible. Utilisez AWS CodePipeline ou GitHub Actions avec des rôles assumés (sts:AssumeRole) pour effectuer des déploiements dans les comptes cibles, en vous assurant que le bootstrap et les rôles liés au service (service-linked roles) nécessaires existent. N’oubliez pas que les exportations CloudFormation sont régionales ; préférez les StackSets ou les déploiements pilotés par un pipeline pour la distribution inter-comptes.

Ressources personnalisées, protection de la pile et accélérateurs de déploiement local et incrémentiel

Utilisez des ressources personnalisées lorsque CloudFormation ne dispose pas d’un type de ressource natif, en implémentant des fournisseurs basés sur Lambda qui respectent le protocole de réponse de CloudFormation pour les événements Create/Update/Delete. Créez des gestionnaires idempotents, répondez avec cfn-response ou le framework CLI de CloudFormation, et gérez les actions de longue durée avec des événements de progression ou en stockant l’état dans DynamoDB. Soyez attentif aux délais d’expiration des ressources personnalisées : CloudFormation a un délai d’expiration maximal pour les opérations de la pile, et les ressources basées sur Lambda doivent se terminer dans cette fenêtre sous peine de provoquer une restauration (rollback) de la pile. Protégez les ressources critiques avec des stratégies de pile (SetStackPolicy) pour bloquer le remplacement ou les mises à jour d’ID logiques spécifiés lors des mises à jour de la pile, et activez la protection contre la terminaison pour les environnements que vous ne pouvez pas vous permettre de supprimer. Pour le développement local et incrémentiel, utilisez AWS SAM CLI (sam build, sam local invoke, sam local start-api) et sam sync pour des mises à jour rapides uniquement du code, et CDK watch ou cdk deploy avec des artefacts pour ne mettre à jour que les ressources modifiées ; ces outils calculent les hachages des artefacts (hachage d’artefact lambda) afin que seul le code modifié soit republié. Intégrez les ChangeSets de CloudFormation, le versionnement Lambda (AutoPublishAlias dans SAM ou lambda.Version dans CDK) et la répartition du trafic de CodeDeploy pour des déploiements sécurisés. Les pièges courants incluent le dépassement des limites de modèle ou de paramètre, l’utilisation incorrecte des importations inter-comptes et l’initialisation de clients SDK lourds à l’intérieur des gestionnaires, ce qui provoque des latences de démarrage à froid (cold start) — préférez des clients globaux, initialisés de manière paresseuse, avec des délais d’expiration et un comportement de nouvelle tentative configurables.

Problème pratique : Scénario d’utilisation

Scénario : AcmeMedia gère une organisation AWS multi-comptes avec des comptes Dev, Staging et Prod distincts dans la région us-east-1. Un service de traitement d’images sans serveur (serverless) (Lambda + S3 + DynamoDB) doit être déployé de manière cohérente sur tous les comptes, avec une configuration sensible partagée et stockée de manière centralisée.

Défi : Déployer la même pile CloudFormation/SAM/CDK sur plusieurs comptes et s’assurer que les artefacts de code Lambda sont disponibles de manière sécurisée dans chaque compte cible, tout en gardant les secrets hors des modèles.

Approche recommandée :

1. Utilisez AWS CloudFormation StackSets avec des autorisations gérées par le service (aws cloudformation create-stack-set –stack-set-name ImageProcessor –template-body file://template.yaml), puis aws cloudformation create-stack-instances pour cibler les comptes et les régions, ou configurez CDK Pipelines pour synthétiser et déployer par compte avec des rôles.
2. Empaquetez les artefacts Lambda en utilisant la publication d’artefacts CDK (cdk bootstrap dans chaque compte/région) ou sam package vers un compartiment S3 dans chaque compte cible ; automatisez la copie des artefacts via la CI (CodeBuild utilisant aws s3 cp ou la réplication S3) et utilisez cdk deploy ou sam deploy avec les identifiants du compte cible.
3. Stockez la configuration sensible dans AWS Secrets Manager dans chaque compte, référencée dans le modèle via des références dynamiques ({{resolve:secretsmanager:arn:aws:secretsmanager:us-east-1:123456789012:secret:ImageProcSecret:SecretString:apiKey}}) ou déployez un secret répliqué via la fonctionnalité de réplication de Secrets Manager, en évitant les paramètres NoEcho.
4. Utilisez les ChangeSets (create-change-set, execute-change-set), activez la protection contre la terminaison sur les piles de production, et utilisez des stratégies de pile pour empêcher le remplacement accidentel des tables DynamoDB ou des compartiments S3 lors des mises à jour.

Justification : Les StackSets et les déploiements pilotés par pipeline assurent une propagation sécurisée et auditable sur plusieurs comptes/régions, tandis que la publication d’artefacts et les secrets par compte gardent les identifiants locaux et auditables. Les ChangeSets, la protection contre la terminaison et les stratégies de pile réduisent les risques lors des déploiements itératifs.

← Amazon DynamoDB et Conception NoSQL · Tous les domaines · Déploiement et CI →

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

Parcourir Amazon →