Amazon SOA-C02: Déploiement, provisionnement et automatisation — Guide d'étude

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fait partie du AWS SysOps Administrator Associate SOA-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.

Ce domaine couvre les méthodes et les outils utilisés pour provisionner, mettre à jour et exploiter les infrastructures AWS et les déploiements d’applications de manière fiable et répétée. Il met l’accent sur le provisionnement déclaratif et idempotent, les pipelines automatisés pour les livraisons, et l’automatisation opérationnelle qui réduit les tâches manuelles tout en préservant l’auditabilité et la sécurité. Les opérateurs doivent trouver un équilibre entre la sécurité (restaurations, politiques de changement) et la vélocité (images immuables, application automatisée des correctifs), et choisir des modèles qui soutiennent la conformité et la capacité de restauration.

CloudFormation et les modèles d’Infrastructure as Code

Utilisez CloudFormation (ou CDK/Terraform) pour déclarer l’infrastructure en tant que code (IaC) afin que les stacks soient idempotentes : un modèle décrit l’état désiré et le moteur fait converger les ressources. Préférez les ressources et les paramètres déclaratifs aux scripts impératifs. Modèles de CLI typiques :

Créer et inspecter un jeu de modifications :

undefined

Examiner et exécuter :

undefined

Déploiement simplifié :

undefined

Décisions de conception :

Utilisez des stacks imbriquées ou des modules pour la réutilisation et les limites ; déplacez les secrets modifiables et les gros binaires hors des modèles (SSM Parameter Store / Secrets Manager).
Utilisez des politiques de stack, la protection contre la suppression et des déclencheurs de restauration pour la sécurité ; activez la détection de dérive avec

undefined

Accordez au rôle de service CloudFormation une politique IAM à portée limitée pour créer des ressources ; évitez de donner à CloudFormation des autorisations d’administrateur étendues.

Comparaison des approches IaC :

CloudFormation/CDK : natif, intégré avec les jeux de modifications et la détection de dérive AWS, nécessite

undefined

pour les ressources IAM.

Terraform : agnostique au fournisseur, gestion de fichier d’état requise, adapté aux environnements multi-cloud.
Scripts impératifs (CLI/SDK) : adaptés aux opérations ponctuelles mais non idempotents et plus difficiles à auditer.

CI/CD et pratiques d’automatisation du déploiement

Implémentez des étapes de pipeline reproductibles : source -> build -> test -> deploy. Utilisez AWS CodePipeline en intégrant CodeBuild, CodeDeploy ou des outils tiers (Jenkins, GitHub Actions). Configurations clés :

CodeBuild : définissez

undefined

pour les phases et les artefacts ; accordez au rôle du projet le moindre privilège (

undefined

pour les entrées,

undefined

pour les artefacts).

CodeDeploy : utilisez des groupes de déploiement et

undefined

; choisissez le type de déploiement — sur place (in-place) ou bleu/vert (blue/green). Pour EC2/ASG, préférez le bleu/vert pour réduire les risques.

ECR + ECS/EKS : poussez les images depuis la CI, taguez-les de manière immuable (sémantique ou ID de build), et référencez le tag ou le digest de l’image dans les définitions de tâches.

Critères de décision pour les stratégies de déploiement :

Utilisez le déploiement bleu/vert ou canary avec basculement de trafic lorsque vous avez besoin d’un temps d’arrêt quasi nul et d’une restauration sûre ; CodeDeploy ou les changements de pondération de l’Application Load Balancer (ALB) le permettent.
Utilisez les mises à jour progressives (rolling) ou sur place (in-place) pour les flottes plus petites et sans état où la capacité peut être réduite pendant la mise à jour.
Assurez-vous que les rôles du pipeline ont une portée limitée : le rôle d’exécution du pipeline, le rôle de service de CodeBuild et le rôle de déploiement (profil d’instance) doivent chacun avoir des autorisations minimales.

Gérez les secrets et les paramètres de manière sécurisée : stockez les paramètres dans SSM Parameter Store (SecureString) ou AWS Secrets Manager ; donnez aux rôles du pipeline les autorisations

undefined

selon les besoins.

Création d’AMI (baking), images immuables et gestion des AMI

L’infrastructure immuable consiste à créer une nouvelle AMI avec tous les correctifs de l’OS et de l’application intégrés (baked in), puis à remplacer les instances au lieu de les modifier. Utilisez EC2 Image Builder ou Packer dans la CI pour produire des AMI automatiquement :

Les pipelines EC2 Image Builder peuvent s’exécuter selon un calendrier, installer des paquets, exécuter des tests et produire des AMI avec des conventions de nommage et des tags versionnés.
Packer s’intègre à la CI (CodeBuild/Jenkins) pour exécuter des scripts de build et générer des ID d’AMI ; stockez l’AMI la plus récente dans SSM Parameter Store (par ex.,

undefined

) pour référence.

Gérer le cycle de vie des AMI :

Taguez les images avec les métadonnées de build et une date d’expiration ; automatisez le déréférencement et la suppression des snapshots après la période de rétention.
Utilisez des Launch Templates/ASG avec une mise à jour de version pour déployer de nouvelles AMI ; pour les déploiements immuables, créez un nouvel ASG référençant la nouvelle version du Launch Template et changez de groupe cible (target group).

Comparaison : modifiable vs immuable :

Immuable (nouvelle AMI/nouvel ASG) : plus sûr, restauration plus facile en basculant vers l’ASG ou l’AMI précédente, cycle de vie cohérent.
Modifiable (correctif sur place) : plus rapide pour appliquer de petites corrections mais risque de dérive plus élevé et plus difficile à reproduire ; à n’utiliser que lorsque les contraintes l’exigent.

Automatisation, Run Command et application de correctifs avec AWS Systems Manager

Systems Manager (SSM) centralise les tâches opérationnelles : Run Command pour les commandes ad-hoc, State Manager pour l’état désiré, Patch Manager pour l’application planifiée de correctifs de système d’exploitation, et Automation pour les workflows complexes. Modèles de CLI courants :

Envoyer une commande ad-hoc :

undefined

Démarrer une automatisation prédéfinie :

undefined

Utiliser les associations State Manager pour appliquer une configuration (par ex., configuration de l’agent SSM, tâches cron) et les référentiels Patch Manager pour les règles d’approbation et les analyses de conformité.

Détails de configuration et points de décision :

Utilisez Patch Manager avec des référentiels (Baselines) et des fenêtres de maintenance (Maintenance Windows) pour une application de correctifs prévisible et conforme ; choisissez les jours d’approbation automatique et rejetez les images AMI non approuvées si vous utilisez une stratégie immuable.
Pour les instances sans agent SSM ou avec un réseau limité, envisagez Session Manager avec des points de terminaison VPC pour éviter d’ouvrir les ports SSH.
Exigez toujours un profil d’instance avec la politique AmazonSSMManagedInstanceCore pour l’accès à SSM ; définissez des autorisations supplémentaires selon les besoins.

Gestion du changement, détection de dérive et restauration (rollback)

Implémentez un contrôle des changements qui intègre les exécutions de pipeline, les balises et les approbations. Utilisez les jeux de modifications (change sets) de CloudFormation pour prévisualiser les différences et les politiques de pile (stack policies) pour rejeter les mises à jour destructrices. Modèles de CLI :

Détecter la dérive :

undefined

Utilisez une politique de pile pour protéger les ressources critiques pendant les mises à jour et définissez une RollbackConfiguration avec des déclencheurs de restauration pour notifier en cas d’échec des mises à jour.

Stratégies de restauration (rollback) :

Pour CloudFormation : la restauration automatique en cas d’échec est le comportement par défaut ; utilisez des déclencheurs de restauration et conservez les ressources lorsque nécessaire.
Pour les applications : préférez les déploiements blue/green ou canary avec basculement de trafic pour permettre une restauration instantanée en modifiant la pondération sur ALB/Route 53 ou en rétablissant les jeux de tâches précédents.
Maintenez des artefacts immuables (ID d’AMI, images de conteneur) et préservez les versions précédentes dans les registres/SSM afin que les restaurations soient déterministes.

Critères de décision :

Si des migrations de données avec état (stateful) sont impliquées, incluez des scripts de migration réversibles ou utilisez des indicateurs de fonctionnalité (feature flags) pour séparer la publication du code de la migration de schéma.
Utilisez des vérifications de l’état de santé du déploiement et des tests de fumée (smoke tests) automatisés comme portes de contrôle (gating) dans le pipeline pour déclencher les restaurations au plus tôt.

Pièges courants et critères de décision

Effectuer des changements manuels hors bande via la console qui provoquent une dérive par rapport à l’état de l’IaC : imposez la détection de dérive (

undefined

) et exigez que les correctifs soient appliqués via les modèles IaC ; utilisez des contrôles IAM pour restreindre les modifications via la console.

Absence de plan de restauration sûr pour les mises en production : adoptez des déploiements blue/green ou canary et conservez les artefacts/AMI précédents disponibles pour revenir en arrière instantanément.
IAM trop permissif pour les pipelines et les rôles : appliquez le principe du moindre privilège ; séparez les rôles (rôle de service du pipeline, rôle de build, profil d’instance) et n’accordez que les accès ssm:GetParameter, secretsmanager:GetSecretValue, kms:Decrypt et S3 nécessaires.
Stockage des secrets directement dans les modèles ou en texte clair : déplacez les secrets vers Secrets Manager ou SSM Parameter Store en tant que SecureString et référencez-les au moment du déploiement avec les autorisations de déchiffrement appropriées.
Application de correctifs en place sur la production sans test : créez (bake) des AMI dans la CI avec les paquets mis à jour et des tests de fumée, puis déployez les images immuables via des pipelines ASG ou blue/green.
Ignorer la dérive et la protection des ressources avec état : utilisez des politiques de pile et détectez la dérive régulièrement ; pour les ressources avec état, exigez une approbation manuelle et des instantanés (snapshots) avant les changements destructeurs.

Problème pratique : Scénario d’utilisation

Acme Payments doit déployer un service d’API conforme à la norme PCI, appliquer des correctifs de système d’exploitation mensuels et être capable de restaurer rapidement si un déploiement provoque des erreurs pendant les heures de bureau.

Implémentez un pipeline immuable : utilisez CodePipeline/CodeBuild pour créer (bake) des AMI avec EC2 Image Builder (ou Packer), balisez les AMI et publiez l’ID de l’AMI dans SSM Parameter Store.
Déployez via des modèles CloudFormation qui référencent le paramètre SSM pour l’AMI et créent une nouvelle version d’ASG + Launch Template pour chaque mise en production ; utilisez les jeux de modifications (change sets) pour un examen préalable (pre-flight).
Utilisez CodeDeploy ou le basculement de trafic blue/green sur les groupes cibles d’ALB avec des vérifications de l’état de santé et des tests de fumée automatisés ; configurez la restauration automatique en cas d’échec de la vérification de l’état de santé.
Planifiez Patch Manager via les fenêtres de maintenance de Systems Manager pour l’application de correctifs en dehors des heures de pointe ; effectuez une création et un déploiement (bake-and-deploy) pour les images corrigées afin d’éviter l’application de correctifs en place sur la production.
Appliquez le moindre privilège IAM pour les rôles de pipeline, stockez les secrets dans Secrets Manager, et activez la détection de dérive de CloudFormation ainsi que les politiques de pile pour les ressources critiques.

Justification : La création d’images et le déploiement immuable séparent les préoccupations de construction (build) et d’exécution (run), fournissant des artefacts reproductibles et des chemins de restauration sûrs ; l’application automatisée de correctifs via SSM ainsi que les déploiements immuables minimisent les risques et soutiennent la conformité tout en maintenant la capacité de récupération.

← Haute disponibilité · Tous les domaines · Sécurité →

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