Amazon SAP-C02: Déploiement, automatisation et DevOps — Guide d'étude

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Fait partie du AWS Solutions Architect Professional SAP-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.

Infrastructure as Code et gestion de l’environnement

Considérez l’Infrastructure as Code (IaC) comme la source unique de vérité pour les environnements, en intégrant les réseaux, IAM et la topologie applicative dans des artefacts réutilisables et versionnés. Choisissez CloudFormation pour un contrôle strict et déclaratif et une intégration profonde avec AWS, et utilisez l’AWS Cloud Development Kit (CDK) lorsque des constructions de plus haut niveau et des abstractions natives au langage améliorent la productivité des développeurs ; forcez toujours la CI à synthétiser le CDK en modèles et à stocker les artefacts dans un bucket S3 chiffré et versionné. Utilisez CloudFormation StackSets pour une instanciation de piles cohérente entre les comptes et les régions, et activez la détection de dérive (drift detection) combinée à une remédiation automatisée via Systems Manager lorsque la dérive indique une entropie de configuration. Créez des images de référence (golden images) avec EC2 Image Builder ou Packer et publiez les AMI sur les comptes et les régions via des pipelines automatisés ; cela prend en charge les déploiements immuables et réduit la dérive de configuration post-lancement. Soyez méticuleux avec les ensembles de modifications (change sets) CloudFormation, la protection contre la suppression (termination protection) et les politiques de mise à jour pour éviter le remplacement involontaire de ressources pouvant entraîner une perte de données. Les pièges courants incluent l’intégration de secrets dans les modèles, le recours à des modifications manuelles non rigoureuses qui invalident la détection de dérive, ou l’octroi de rôles d’exécution CloudFormation trop permissifs — limitez les rôles d’exécution au moindre privilège (least privilege) et conservez l’historique de CloudTrail et de Config à des fins d’audit. Les compromis sont clairs : le CDK accélère le développement mais exige une CI/CD rigoureuse pour éviter les piles d’exécution non synchronisées ; CloudFormation pur est plus rigide mais immédiatement auditable.

Pipelines CI/CD et stratégies de déploiement

Concevez des pipelines qui séparent les étapes de construction (build), de test et de déploiement, et qui automatisent les décisions de restauration (rollback). AWS CodePipeline, CodeBuild et CodeDeploy fournissent un chemin entièrement géré pour les flux allant de la source à la production, tandis que les systèmes tiers (GitHub Actions, Jenkins, GitLab) s’intègrent avec les services AWS pour le stockage d’artefacts (S3), les registres de conteneurs (ECR) et les hooks de déploiement. Pour les stratégies d’exécution, préférez les déploiements immuables ou bleu/vert (blue/green) pour les services avec état (stateful) ou avec session (sessionful) afin d’éliminer la dérive de configuration sur place ; utilisez des déploiements canary avec basculement de trafic (traffic shifting) pour une réduction incrémentale du risque. Pour Lambda, utilisez des alias et un basculement de trafic pondéré (weighted traffic shifting) avec des alarmes CloudWatch ou CodeDeploy pour une restauration automatisée. Pour ECS/EKS, combinez les contrôleurs de déploiement (CodeDeploy, AWS App Mesh ou les stratégies natives de Kubernetes) avec le drainage des groupes cibles d’ALB (target group draining) et les hooks de cycle de vie (lifecycle hooks) pour garantir un arrêt en douceur (graceful shutdown). Faites attention aux changements de schéma de base de données : concevez des migrations rétrocompatibles et utilisez des indicateurs de fonctionnalité (feature flags) (AWS AppConfig) ou des lancements discrets (dark launches) pour découpler le déploiement du code de l’évolution du schéma. Les considérations de coût par rapport à la vitesse sont importantes : les déploiements canary ralentissent les lancements mais minimisent le rayon d’impact (blast radius), tandis que le bleu/vert en parallèle double le coût de l’infrastructure pendant la fenêtre de basculement. Intégrez toujours les politiques de déploiement, les vérifications de santé (health checks) et les restaurations automatiques dans les pipelines pour éviter toute intervention manuelle lors d’incidents.

Automatisation, conformité de la configuration et observabilité

L’excellence opérationnelle repose sur la remédiation automatisée, une configuration cohérente et une observabilité holistique. AWS Systems Manager fournit le Parameter Store pour la configuration, les documents Automation pour les runbooks, le Patch Manager pour la maintenance de base, et le Session Manager pour le dépannage sans bastion. Utilisez EventBridge comme bus d’événements central pour l’automatisation découplée — routez les événements CloudTrail, Config ou applicatifs vers des fonctions Lambda ou des Step Functions pour une remédiation orchestrée. Appliquez des garde-fous (guardrails) avec les règles AWS Config et un Config Aggregator pour auditer plusieurs comptes, et mettez en œuvre des playbooks de remédiation automatisée via Systems Manager ou EventBridge pour les ressources non conformes. Pour l’observabilité, instrumentez les services avec les métriques et les journaux (Logs) CloudWatch, activez X-Ray ou AWS Distro for OpenTelemetry pour le traçage distribué, et centralisez les journaux avec les abonnements CloudWatch Logs ou Kinesis Firehose dans un lac de données (data lake) S3 centralisé et une pile analytique. Les pièges courants incluent une rétention de journaux illimitée qui fait exploser les coûts, des métriques personnalisées à haute cardinalité qui font exploser les coûts des métriques, l’absence d’ID de corrélation qui rend les traces inutiles, et le fait de ne pas tester les runbooks de remédiation en pré-production. Les compromis tournent autour de la granularité de la télémétrie par rapport aux coûts d’ingestion et de stockage ; l’échantillonnage des traces et une rétention courte réduisent les coûts mais peuvent masquer des défaillances rares et critiques. Concevez des alertes et des tableaux de bord ciblés sur des signaux exploitables (actionable signals) pour maintenir une charge opérationnelle gérable.

Performances, services avec état, sécurité et considérations interrégionales

Choisissez les services de stockage et avec état en fonction du modèle d’accès, des besoins en latence et des exigences de cohérence. Les caches en mémoire offrent des lectures en moins d’une milliseconde ; ElastiCache (Redis) prend en charge les ensembles ordonnés, idéaux pour les classements, et fournit la réplication, la persistance et Global Datastore pour une localité de lecture interrégionale. DynamoDB est excellent pour le stockage durable à grande échelle et peut être associé à DAX pour l’accélération des lectures, bien que DAX soit plus adapté à un accès au niveau de l’élément et pouvant être mis en cache, et présente des compromis en matière de cohérence à terme (eventual consistency). Pour les applications héritées (legacy) basées sur des fichiers, envisagez Amazon FSx for NetApp ONTAP ou Amazon EFS avec DataSync pour une compatibilité « lift-and-shift » ; pour une sémantique SMB/NFS, FSx est souvent l’option la moins risquée. Le chiffrement et la réplication comportent des pièges subtils : les clés AWS KMS sont régionales et doivent être gérées par Région pour la réplication S3 interrégionale, ou utilisez des clés multi-Régions pour simplifier les modèles d’accès ; soyez prudent avec les politiques de clés et les autorisations inter-comptes. Les fonctions Lambda dans les VPC subissent des démarrages à froid (cold-starts) en raison de la création d’ENI — atténuez ce phénomène avec des points de terminaison VPC, des paquets de plus petite taille, la simultanéité provisionnée, ou en utilisant des Lambdas en dehors du VPC avec RDS Proxy. Évaluez le coût par rapport à la résilience : les tables globales et la réplication interrégionale améliorent le RTO/RPO pour un coût accru ; la simultanéité provisionnée réduit la latence mais augmente les dépenses de base. Tenez compte des besoins en durabilité des données, des délais de reprise après sinistre (DR) et des limites de ressources par compte lors du choix des architectures.

Problème pratique : Scénario d’utilisation

Scénario : SkyForge Games exploite un environnement AWS existant avec des comptes de production et de pré-production (staging) répartis sur deux Régions. Le classement actuel est implémenté dans DynamoDB et servi par des API Lambda déployées via CodePipeline ; les joueurs s’attendent à une latence de lecture de l’ordre de la microseconde et à un temps d’arrêt quasi nul lors des fréquentes publications de nouvelles fonctionnalités.

Défi : Fournir des lectures du classement en quelques microsecondes tout en maintenant la durabilité et en construisant un pipeline CI/CD sûr et automatisé qui prend en charge des déploiements rapides, avec capacité de restauration (rollback), sur plusieurs comptes et Régions.

Approche recommandée :

1. Provisionnez un cluster ElastiCache for Redis avec le mode cluster activé (Cluster Mode Enabled) dans la Région principale pour le chemin d’accès critique (hot-path) du classement, avec des réplicas dans plusieurs AZ et la persistance Redis (AOF) activée ; configurez Global Datastore pour la localité de lecture dans la Région secondaire.
2. Conservez DynamoDB comme source de vérité ; utilisez DynamoDB Streams + Lambda (ou Kinesis Data Streams) pour mettre à jour Redis de manière asynchrone, garantissant ainsi la cohérence à terme (eventual consistency) et la rejouabilité pour la récupération.
3. Implémentez un pipeline basé sur CDK (CDK Pipelines ou CodePipeline déclenché par Git) qui synthétise les modèles, compile les artefacts dans S3/ECR chiffrés, et déploie l’infrastructure via des CloudFormation StackSets vers les comptes/Régions cibles ; incluez des tests de fumée (smoke tests) automatisés et des portes d’approbation.
4. Déployez les modifications applicatives en utilisant une stratégie canary/bleu-vert : utilisez des alias Lambda pondérés ou le basculement de groupes cibles ALB (target-group shifting) avec des alarmes CloudWatch et une restauration automatique (rollback) ; instrumentez avec CloudWatch, X-Ray et des vérifications canary synthétiques.

Justification : Utilisez Redis pour des lectures réelles en moins d’une milliseconde tout en conservant la durabilité et la rejouabilité de DynamoDB ; le CI/CD avec CDK et les StackSets fournit des déploiements multi-comptes cohérents et auditables, et le basculement de trafic (traffic-shifting) ainsi que l’observabilité permettent des livraisons itératives sûres avec une restauration rapide.

← Optimisation des coûts et gouvernance · Tous les domaines

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

Parcourir Amazon →