Accueil Blog Certification AWS Solutions Architect Associate – Guide de préparation complet 2026
Study Guide · 21 mai 2026

Certification AWS Solutions Architect Associate – Guide de préparation complet 2026

LeCloudFacile

Ce Study Guide couvre l’intégralité du programme officiel SAA-C03. Il est organisé autour des 4 domaines officiels avec pour chacun : les concepts clés, les architectures de référence, les services incontournables, les pièges fréquents et des questions types commentées.

Comptez 2 à 4 mois de préparation à raison de 1h30 par jour.

1. Comprendre la certification SAA-C03

Ce qui change par rapport au Cloud Practitioner CLF-C02

Le CLF-C02 testait votre compréhension du cloud.

Le SAA-C03 teste votre capacité à CONCEVOIR des architectures cloud. Ce n’est pas la même chose.

 

Cloud Practitioner (CLF-C02)

Solutions Architect (SAA-C03)

Ce qu’il teste

Compréhension des services

Capacité à concevoir des architectures

Question type

“À quoi sert S3 ?”

“Comment concevoir un système HA avec S3 et Lambda ?”

Profondeur

Large mais peu profond

Profond — comprendre les nuances

Pratique requise

Utile mais optionnelle

Fortement recommandée

Durée exam

90 minutes

130 minutes

Coût

100 USD

300 USD 

Les 5 piliers du Well-Architected Framework — le fil rouge du SAA-C03

Tout le SAA-C03 s’articule autour du Well-Architected Framework d’AWS — 5 piliers que chaque question teste d’une façon ou d’une autre. Apprenez-les par cœur.

#

Pilier

Ce qu’il signifie

Services clés

1

Excellence opérationnelle

Automatiser les opérations, améliorer continuellement

CloudFormation, Systems Manager, CloudWatch, CodeDeploy

2

Sécurité

Protéger les données, les systèmes et les actifs

IAM, KMS, GuardDuty, Shield, WAF, Macie

3

Fiabilité

Récupérer des pannes, scaler dynamiquement

Multi-AZ, Auto Scaling, Route 53, RDS Multi-AZ, ELB

4

Performance

Utiliser les ressources de façon efficiente

ElastiCache, CloudFront, RDS Read Replicas, EBS io2

5

Optimisation des coûts

Éviter les dépenses inutiles

Reserved Instances, Spot, S3 Intelligent-Tiering, Trusted Advisor

2. Les 4 domaines et leur pondération

#

Domaine

Poids

Questions (~)

1

Conception d’architectures sécurisées

30%

~15 questions notées — le plus lourd

2

Conception d’architectures résilientes

26%

~13 questions notées

3

Conception d’architectures performantes

24%

~12 questions notées

4

Conception d’architectures rentables

20%

~10 questions notées

 

Stratégie : Domaine 1 (Sécurité, 30%) + Domaine 2 (Résilience, 26%) = 56% de l’examen. Concentrez votre temps sur ces deux domaines. Le Domaine 4 (Coûts, 20%) est souvent plus accessible — ne le négligez pas mais il nécessite moins de profondeur technique.

2.1 Domaine 1  – Conception d’architectures sécurisées (30% de l’examen) 

2.1.1 IAM avancé — au-delà des bases

Pour le SAA-C03, IAM va bien au-delà du CLF-C02. Vous devez comprendre les nuances des politiques, des rôles inter-comptes et des conditions.

  •       Politiques basées sur les ressources (Resource-based policies) : Attachées directement à une ressource (ex : politique de bucket S3). Permettent l’accès inter-comptes sans assumer un rôle.
  •       Politiques basées sur les identités (Identity-based policies) : Attachées à un utilisateur, groupe ou rôle IAM. Définissent ce que l’identité peut faire.
  •       SCP (Service Control Policies) : Dans AWS Organizations, limitent les permissions maximales de tous les comptes membres — même si un admin IAM du compte a des droits complets.
  •       Permission boundaries : Définissent les permissions maximales qu’un rôle ou utilisateur peut avoir — utile pour déléguer la création de rôles sans risque de privilege escalation.
  •       IAM Roles for EC2 : Évitez les access keys sur les instances EC2. Utilisez des rôles IAM attachés à l’instance — credentials temporaires gérés automatiquement par AWS.
  •       AssumeRole et cross-account access : Permet à un compte AWS d’assumer un rôle dans un autre compte. Pattern courant pour les architectures multi-comptes.

Piège fréquent : Ordre d’évaluation des politiques IAM : DENY explicite > ALLOW explicite > DENY implicite (refus par défaut). Si une SCP refuse une action, même un admin IAM du compte ne peut pas l’effectuer.

2.1.2 VPC — Architecture réseau sécurisée

Le VPC est au cœur de toute architecture sécurisée sur AWS. Vous devez maîtriser tous ses composants pour le SAA-C03.

  •       Subnets publics vs privés : Subnet public = route vers Internet Gateway (IGW). Subnet privé = pas de route directe vers Internet. Les ressources critiques (BDD, services internes) vont dans les subnets privés.
  •       Security Groups vs NACLs : Security Group = stateful, par instance, ALLOW uniquement. NACL = stateless, par subnet, ALLOW et DENY. Security Group s’applique aux instances, NACL aux subnets.
  •       NAT Gateway vs NAT Instance : NAT Gateway = managé, haute disponibilité, recommandé. NAT Instance = EC2 que vous gérez, moins cher mais moins fiable. Les instances dans les subnets privés utilisent NAT pour accéder à Internet (updates, patches).
  •       VPC Peering : Connexion privée entre deux VPC (même compte ou comptes différents, même région ou cross-region). Non transitif : si A peer B et B peer C, A ne voit pas C.
  •       AWS Transit Gateway : Hub central qui connecte plusieurs VPC et réseaux on-premise. Transitivité native. Remplace les architectures VPC peering complexes.
  •       VPC Endpoints : Connexion privée entre votre VPC et les services AWS sans passer par Internet. Gateway Endpoint (S3, DynamoDB, gratuit). Interface Endpoint (PrivateLink, payant).
  •       AWS PrivateLink : Expose un service dans votre VPC à d’autres VPC de façon privée et sécurisée. Utilisé par les services AWS managés et pour le partage de services entre comptes.

 

Security Group

NACL

Quand utiliser

Niveau

Instance / ENI

Subnet

 

Stateful/Stateless

Stateful (retour auto)

Stateless (règles retour)

 

Règles

ALLOW uniquement

ALLOW et DENY

NACL pour blocage IP, SG pour contrôle par instance

Ordre d’évaluation

Toutes les règles

Numéro croissant

 

 

2.1.3 Chiffrement et gestion des secrets

  •       AWS KMS (Key Management Service) : Génère, stocke et gère les clés de chiffrement. CMK (Customer Master Keys) : AWS managed (gratuit, contrôle limité) ou Customer managed (payant, contrôle total). Utilisé par S3, EBS, RDS, Secrets Manager…
  •       AWS Secrets Manager : Stocke et fait tourner automatiquement les credentials (BDD passwords, clés API). Intégration native avec RDS. À préférer à SSM Parameter Store pour les secrets sensibles avec rotation.
  •       SSM Parameter Store : Stockage de paramètres et de secrets. SecureString = chiffré avec KMS. Moins cher que Secrets Manager, mais pas de rotation automatique native.
  •       S3 encryption options : SSE-S3 (clés gérées par AWS, gratuit), SSE-KMS (vos clés CMK, payant, audit dans CloudTrail), SSE-C (vous fournissez la clé), CSE (chiffrement côté client avant upload).
  •       EBS encryption : Chiffrement des volumes EBS via KMS. Les snapshots d’un volume chiffré sont automatiquement chiffrés.

2.1.4 Services de sécurité avancés

  •       AWS WAF : Web Application Firewall. Protège contre les attaques couche 7 (SQL injection, XSS, bots). S’applique sur CloudFront, ALB, API Gateway, AppSync. Règles managées AWS disponibles.
  •       AWS Shield Standard vs Advanced : Standard = gratuit, protection DDoS de base automatique. Advanced = payant (~3000 USD/mois), protection avancée, équipe DDoS Response Team (DRT), remboursement des surcoûts EC2/ELB liés aux attaques.
  •       Amazon GuardDuty : Détection de menaces ML/anomalie sur CloudTrail, VPC Flow Logs, DNS logs. Pas de configuration manuelle — active immédiatement. Alerte sur instance compromise, accès inhabituel, crypto-mining…
  •       AWS Security Hub : Agrège et priorise les alertes de sécurité de GuardDuty, Inspector, Macie, IAM Access Analyzer en une vue unifiée.
  •       Amazon Macie : Détecte automatiquement les données sensibles (PII, secrets) dans S3 via ML.
  •       IAM Access Analyzer : Identifie les ressources partagées avec des entités externes (S3, KMS, Lambda, SQS…). Génère des alertes quand une ressource est accessible depuis l’extérieur du compte.

2.2 Domaine 2 : Conception d’architectures résilientes (26% de l’examen) 

2.2.1 Haute disponibilité vs Tolérance aux pannes vs Reprise après sinistre

 

HA (Haute Disponibilité)

FT (Tolérance aux pannes)

DR (Reprise après sinistre)

Objectif

Minimiser les interruptions

Continuer sans interruption

Récupérer après un sinistre majeur

Interruption

Courte interruption possible

Aucune interruption

Interruption acceptable selon RTO

Coût

Modéré

Élevé

Variable selon stratégie

Exemple AWS

RDS Multi-AZ

Cluster actif-actif multi-région

Pilot Light ou Warm Standby 

2.2.2 RTO et RPO — les métriques de la résilience

  •       RTO (Recovery Time Objective) : Temps maximal acceptable avant que le système soit de nouveau opérationnel. “Combien de temps peut-on être en panne ?” Un RTO de 1h signifie que le système doit reprendre en moins de 1h.
  •       RPO (Recovery Point Objective) : Perte de données maximale acceptable. “Jusqu’à quand peut-on perdre des données ?” Un RPO de 15 min signifie qu’on peut perdre au maximum 15 min de données — donc les sauvegardes doivent être faites toutes les 15 min.

Mémo : RTO = temps avant reprise · RPO = données perdues. RTO et RPO faibles = architecture plus chère (Warm Standby, Multi-Region Active-Active). RTO et RPO élevés = architecture moins chère (Backup & Restore).

2.2.3 Stratégies de Disaster Recovery (DR)

Stratégie

RTO

Coût

Comment ça marche

Backup & Restore

Heures

Le moins cher

Sauvegardes régulières dans S3/Glacier. Restauration manuelle en cas de sinistre.

Pilot Light

Dizaines de min

Faible

Infrastructure minimale toujours active en région DR. Scale-up rapide en cas de sinistre.

Warm Standby

Minutes

Modéré

Copie réduite mais fonctionnelle de l’infrastructure toujours active. Scale-up en cas de sinistre.

Multi-Region Active-Active

Secondes / Zéro

Le plus cher

Infrastructure complète dans 2+ régions, trafic distribué en temps réel. Aucune interruption.

 

2.2.4 Scalabilité et Auto Scaling

  •       Auto Scaling Group (ASG) : Lance et termine automatiquement des instances EC2 selon des politiques (target tracking, step scaling, scheduled). Toujours déployer derrière un ELB.
  •       Target Tracking Scaling : Maintient une métrique cible (ex : CPU à 50%). AWS ajuste le nombre d’instances automatiquement. Le plus simple et le plus recommandé.
  •       Step Scaling : Ajoute/supprime un nombre défini d’instances en réponse à des alarmes CloudWatch. Plus de contrôle que Target Tracking.
  •       Scheduled Scaling : Scale selon un planning prédéfini (ex : scale-up le lundi matin à 8h). Idéal pour les charges prévisibles.
  •       Predictive Scaling : ML prédit la charge future et scale proactivement. Idéal pour les charges cycliques.
  •       Launch Templates vs Launch Configurations : Utilisez Launch Templates (plus récent, supporte Spot + On-Demand, versions).

2.2.5 Elastic Load Balancing (ELB)

  •       Application Load Balancer (ALB) : Couche 7 (HTTP/HTTPS). Routage basé sur l’URL, les headers, les paramètres de requête. Supporte WebSockets, gRPC. Pour les microservices et conteneurs.
  •       Network Load Balancer (NLB) : Couche 4 (TCP/UDP). Ultra-haute performance, latence minimale (millisecondes). IP statique par AZ. Pour les applications nécessitant des performances extrêmes.
  •       Gateway Load Balancer (GWLB) : Pour les appliances de sécurité (firewalls, IDS/IPS) — distribue le trafic vers des instances de sécurité tierces.
  •       Classic Load Balancer (CLB) : Ancienne génération. Évitez pour les nouvelles architectures. Encore présent dans l’examen pour les questions de migration.

Mémo ELB : ALB = HTTP/HTTPS, microservices, conteneurs, routage avancé · NLB = TCP/UDP, haute performance, IP statique · GWLB = appliances de sécurité

2.2.6 Bases de données — Résilience

  •       RDS Multi-AZ : Réplique synchrone dans une AZ différente. Failover automatique en cas de panne (60-120 secondes). Pour la haute disponibilité — pas pour les performances en lecture.
  •       RDS Read Replicas : Réplique asynchrone pour les lectures. Peut être dans la même AZ, une AZ différente, ou une région différente. Pour les performances, pas pour le failover automatique.
  •       Aurora Multi-AZ : 6 copies des données dans 3 AZ automatiquement. Failover en moins de 30 secondes. Aurora Global Database = réplication inter-région avec RPO < 1 seconde.
  •       DynamoDB Global Tables : Réplication multi-région active-active pour DynamoDB. RPO de secondes, RTO proche de zéro. Idéal pour les applications mondiales nécessitant de faibles latences partout.
  •       ElastiCache : Redis (supports clustering, persistence, pub/sub, Sorted Sets) vs Memcached (simple, multi-thread, horizontal scaling). Redis Multi-AZ pour la HA.

2.3 Domaine 3 : Conception d’architectures performantes  (24% de l’examen)

2.3.1 Choisir le bon type de stockage

Service

Type

Cas d’usage

À savoir pour l’examen

S3

Objets

Fichiers statiques, backups, data lake, sites web statiques

Classes de stockage : Standard > IA > One Zone-IA > Glacier Instant > Glacier Flexible > Glacier Deep Archive

EBS gp3

Blocs SSD

OS, applications, bases de données

Attaché à une seule instance EC2. gp3 remplace gp2 (plus flexible et moins cher). io2 pour IOPS très élevés

EFS

Fichiers NFS

Partage de fichiers entre plusieurs EC2, content management

Multi-AZ. Accessible depuis plusieurs instances simultanément. Scale automatique

FSx for Windows

Fichiers SMB

Workloads Windows, Active Directory, SharePoint

Protocole SMB/CIFS, supporte Active Directory. FSx for Lustre = HPC, ML, video processing

Instance Store

Éphémère

Cache temporaire, données qui peuvent être perdues

Très haute performance, données perdues si l’instance s’arrête — temporaire uniquement
2.3.2 Accélération et mise en cache
  •       Amazon ElastiCache for Redis : Cache en mémoire pour réduire la charge sur la base de données. Session storage, leaderboards (Sorted Sets), pub/sub. Latence sous la milliseconde.
  •       Amazon ElastiCache for Memcached : Cache simple multi-thread. Pas de persistence, pas de clustering natif. Pour les architectures qui nécessitent un cache horizontal simple.
  •       Amazon CloudFront : CDN global — cache le contenu dans les edge locations. Réduction de latence pour les utilisateurs finaux. Intégration avec S3, EC2, ELB, API Gateway. Lambda@Edge pour la logique à la périphérie.
  •       AWS Global Accelerator : Améliore les performances des applications globales en utilisant le réseau backbone AWS. Redirige les utilisateurs vers le point d’entrée optimal. IP statiques Anycast. Différent de CloudFront : Global Accelerator optimise le routage réseau, CloudFront cache le contenu.
  •       DynamoDB DAX : Cache en mémoire natif pour DynamoDB. Latence de microsecondes. Compatible avec les APIs DynamoDB existantes — pas de changement de code.
  •       Amazon RDS Read Replicas : Décharge les lectures depuis le serveur principal. Jusqu’à 5 réplicas en lecture pour MySQL/PostgreSQL/MariaDB, 15 pour Aurora.

CloudFront vs Global Accelerator : CloudFront = cache de contenu (HTTP), réduit la latence par le caching · Global Accelerator = optimise le routage réseau (tout protocole), réduit la latence par le routage. Utilisez CloudFront pour les sites web/APIs. Utilisez Global Accelerator pour les applications gaming, IoT, VoIP.

2.3.3 Architectures serverless et découplées

  •       AWS Lambda : Fonctions serverless. Jusqu’à 15 min d’exécution. 10 Go de mémoire max. Concurrence : 1000 exécutions simultanées par défaut (augmentable). Cold start = délai au premier appel après inactivité.
  •       Amazon API Gateway : Crée, publie, maintient et sécurise des APIs REST, HTTP et WebSocket. Intégration native avec Lambda, DynamoDB, S3. Throttling, cache, authentification via Cognito ou Lambda Authorizer.
  •       Amazon SQS : File d’attente. Standard Queue (au moins une fois, ordre non garanti) vs FIFO Queue (exactement une fois, ordre garanti). Visibility Timeout = temps pendant lequel un message est invisible après lecture. DLQ (Dead Letter Queue) = pour les messages qui échouent trop de fois.
  •       Amazon SNS : Pub/sub. Un message → plusieurs abonnés (email, SMS, SQS, Lambda, HTTP). Fan-out pattern : SNS → plusieurs SQS pour traitement parallèle.
  •       Amazon EventBridge : Bus d’événements. Connecte des sources (AWS services, applications SaaS, code custom) à des destinations (Lambda, SQS, SNS…). Règles basées sur le contenu des événements. Remplace progressivement CloudWatch Events.
  •       AWS Step Functions : Orchestration de workflows (séquences de Lambda, services AWS). Standard Workflows (durée jusqu’à 1 an) vs Express Workflows (jusqu’à 5 min, haute fréquence).

2.4 Domaine 4 : Conception d’architectures rentables (20% de l’examen)

2.4.1 Choisir le bon modèle de tarification EC2

Modèle

Économie vs OD

Engagement

Quand l’utiliser

On-Demand

0%

Aucun

Charges imprévisibles, tests, développement, pics courts

Reserved 1 an

~40%

1 an

Charges stables et prévisibles sur 1 an

Reserved 3 ans

~75%

3 ans

Charges stables long terme, workloads bien établis

Savings Plans

~66%

1 ou 3 ans

Flexibilité sur le type d’instance et la région — recommandé vs Reserved

Spot Instances

jusqu’à 90%

Aucun

Charges tolérantes aux interruptions : batch, ML training, rendering

Dedicated Hosts

Variable

Optionnel

Licences logicielles liées au socket/core physique (SQL Server, Oracle)

2.4.2 Optimisation des coûts S3

  •       S3 Standard : Accès fréquent (>1 fois/mois). Coût de stockage élevé, pas de frais de récupération.
  •       S3 Standard-IA (Infrequent Access) : Accès peu fréquent mais récupération rapide. Moins cher que Standard pour le stockage, frais de récupération.
  •       S3 One Zone-IA : Comme Standard-IA mais stocké dans une seule AZ. 20% moins cher, mais moins résilient. Pour les données reproductibles.
  •       S3 Glacier Instant Retrieval : Archives avec accès en millisecondes. Pour les données accédées rarement (1 fois par trimestre).
  •       S3 Glacier Flexible Retrieval : Archives avec récupération en minutes à heures. Pour les sauvegardes à long terme.
  •       S3 Glacier Deep Archive : Stockage le moins cher (environ 0,001 USD/Go/mois). Récupération en 12 à 48h. Pour l’archivage réglementaire long terme.
  •       S3 Intelligent-Tiering : Déplace automatiquement les objets entre les classes de stockage selon les patterns d’accès. Idéal quand les patterns sont imprévisibles.
  •       S3 Lifecycle Policies : Règles automatiques pour déplacer les objets entre classes ou les supprimer selon leur âge. Ex : Standard → IA après 30 jours → Glacier après 90 jours → supprimer après 1 an.

2.4.3 Outils FinOps AWS

  •       AWS Cost Explorer : Analyse et visualisation des coûts historiques. Prévisions à 12 mois. Identification des ressources les plus coûteuses.
  •       AWS Budgets : Alertes quand les coûts, l’utilisation ou les RI/Savings Plans dépassent un seuil. Actions automatiques possibles (ex : arrêter des instances EC2 si budget dépassé).
  •       AWS Trusted Advisor : Recommandations d’optimisation des coûts : instances EC2 sous-utilisées, Reserved Instances non utilisées, buckets S3 avec accès public non nécessaire…
  •       AWS Compute Optimizer : Recommandations ML pour rightsize vos instances EC2, Lambda et EBS. Analyse l’utilisation réelle et suggère le type optimal.
  •       AWS Cost and Usage Report (CUR) : Rapport CSV/Parquet détaillé de toutes les dépenses. Exporté vers S3. Base pour les dashboards FinOps avancés.

3. Les patterns d’architecture incontournables

Le SAA-C03 vous présente des scénarios et vous demande de choisir la meilleure architecture. Voici les patterns les plus fréquents.

Pattern 1 — Architecture 3-tiers classique

Scénario : Application web haute disponibilité.

  •       Internet → Route 53 → CloudFront → ALB (multi-AZ) → EC2 dans ASG (multi-AZ) → RDS Multi-AZ (subnets privés)
  •       Sécurité : EC2 dans subnets privés, RDS dans subnets privés isolés, security groups en cascade (ALB → EC2 → RDS)
  •       Résilience : Multi-AZ pour EC2 (ASG) et RDS, ALB distribue le trafic, Route 53 health checks

Pattern 2 — Architecture serverless

Scénario : API backend sans serveur à gérer.

  •       Client → CloudFront → API Gateway → Lambda → DynamoDB
  •       Avantages : Pas d’infrastructure à gérer, facturation à l’usage, scalabilité automatique
  •       Attention : Cold starts Lambda, limites de concurrence, pas adapté aux traitements longs (>15 min)

Pattern 3 — Architecture découplée avec files de messages

Scénario : Découpler un service producteur d’un service consommateur.

  •       Producteur → SQS → Consommateur (EC2 ou Lambda) → Base de données
  •       Avantages : Le consommateur peut scaler indépendamment, tolérance aux pannes, pas de perte de messages
  •       Fan-out : Producteur → SNS → plusieurs SQS → plusieurs consommateurs en parallèle

Pattern 4 — Disaster Recovery multi-région

Scénario : RTO < 15 min, RPO < 1 min — Warm Standby inter-région.

  •       Région principale : EC2 + RDS Multi-AZ
  •       Région DR : infrastructure réduite toujours active, RDS Read Replica cross-region
  •       Failover : Route 53 health checks + failover routing → promotion de la Read Replica en primary

Pattern 5 — Data lake sur S3

Scénario : Analyser de grands volumes de données à moindre coût.

  •       Sources → Kinesis Data Streams/Firehose → S3 (data lake)
  •       Analyse : AWS Glue (ETL) → Athena (SQL sur S3) → QuickSight (visualisation)
  •       Coût : Très faible — S3 pour le stockage, Athena facture par données scannées, pas d’infrastructure dédiée

Pattern 6 — Architecture hybride cloud/on-premise

Scénario : Connecter un datacenter existant à AWS.

  •       VPN Site-to-Site : Tunnel chiffré sur Internet. Rapide à déployer, moins cher, mais latence variable.
  •       AWS Direct Connect : Connexion dédiée physique entre votre datacenter et AWS. Latence prévisible, bande passante élevée, plus sécurisé. Délai de déploiement : semaines à mois.
  •       AWS Storage Gateway : Intègre le stockage on-premise avec S3/EBS/Tape. Pour la migration progressive ou les architectures hybrides backup.

Mémo Direct Connect vs VPN : Direct Connect = connexion physique dédiée, latence stable, bande passante garantie, cher, délai de déploiement long · VPN Site-to-Site = tunnel IPSec sur Internet, rapide à déployer, moins cher, mais latence variable. Pour les architectures critiques : Direct Connect. Pour les besoins immédiats ou secondaires : VPN

4. Questions types commentées

Voici 20 questions représentatives du niveau et du style du SAA-C03. Le SAA-C03 présente toujours des scénarios d’entreprise — lisez attentivement les contraintes de chaque question. 

❓ Une entreprise gère une application web critique avec un RTO de 30 minutes et un RPO de 5 minutes. Quelle stratégie de DR est la plus appropriée ?

  1. Backup & Restore vers S3
  2. Pilot Light dans une région secondaire
  3. Warm Standby dans une région secondaire  ✓
  4. Multi-Region Active-Active

Explication : RTO 30 min et RPO 5 min orientent vers Warm Standby. Backup & Restore (A) a un RTO de plusieurs heures. Pilot Light (B) nécessite un temps de scale-up qui peut dépasser 30 min. Multi-Region Active-Active (D) est overkill et très coûteux pour ces métriques. Warm Standby maintient une copie réduite fonctionnelle qui peut être scalée rapidement.

❓ Une application doit stocker des données fréquemment accédées et des archives rarement consultées. Quelle solution S3 minimise les coûts sans gestion manuelle ?

  1. S3 Standard pour tout
  2. S3 Standard + Lifecycle Policy vers Glacier après 90 jours
  3. S3 Intelligent-Tiering  ✓
  4. S3 Glacier uniquement

Explication : S3 Intelligent-Tiering déplace automatiquement les objets entre les niveaux d’accès (Standard → IA → Archive) selon les patterns réels d’accès, sans frais de récupération supplémentaires pour Standard et IA. Les Lifecycle Policies (B) sont une bonne alternative mais nécessitent de connaître à l’avance les patterns d’accès — Intelligent-Tiering s’adapte automatiquement.

❓ Une start-up a besoin d’une architecture web hautement disponible mais avec un budget minimal. Quelle architecture est la plus rentable ?

  1. EC2 Reserved Instances + RDS Multi-AZ dans 3 régions
  2. EC2 Spot Instances + Auto Scaling + ALB + RDS Multi-AZ dans 2 AZ
  3. EC2 On-Demand dans une seule AZ + RDS Single-AZ
  4. Lambda + API Gateway + DynamoDB  ✓

Explication : Pour une start-up avec budget minimal et besoin de HA, l’architecture serverless Lambda + API Gateway + DynamoDB est la plus rentable — facturation à l’usage exact, scalabilité automatique, aucun serveur à gérer. EC2 + RDS (B) est viable mais plus coûteux. Multi-région (A) est excessif. Single-AZ (C) n’est pas HA.

❓ Un architecte doit s’assurer que les instances EC2 dans un subnet privé peuvent télécharger des mises à jour depuis Internet, sans être directement accessibles depuis Internet. Quelle est la bonne solution ?

  1. Attacher une Elastic IP à chaque instance EC2
  2. Déployer une NAT Gateway dans le subnet public et mettre à jour la table de routage du subnet privé  ✓
  3. Déployer un Internet Gateway dans le subnet privé
  4. Modifier les NACLs pour autoriser le trafic entrant depuis Internet

Explication : NAT Gateway dans le subnet public permet aux instances du subnet privé d’initier des connexions sortantes vers Internet (pour les updates), sans exposer les instances directement à Internet. Les connexions initiées depuis Internet sont bloquées. Elastic IP (A) rend les instances directement accessibles. IGW dans le subnet privé (C) n’existe pas — l’IGW est au niveau VPC.

❓ Une application reçoit des pics de trafic imprévisibles. Les requêtes doivent être traitées dans l’ordre et chaque message ne doit être traité qu’une seule fois. Quel service AWS est le plus adapté ?

  1. SQS Standard Queue
  2. SQS FIFO Queue  ✓
  3. SNS
  4. Amazon Kinesis Data Streams

Explication : SQS FIFO garantit l’ordre de traitement (First-In, First-Out) ET le traitement exactement une fois (exactly-once processing). SQS Standard (A) offre au moins une fois mais pas d’ordre garanti. SNS (C) est pour le pub/sub, pas pour la garantie d’ordre. Kinesis (D) maintient l’ordre par shard mais la question spécifie le traitement unique.

❓ Quel est le moyen le plus sécurisé de permettre à une application sur EC2 d’accéder à un bucket S3 ?

  1. Stocker les access keys AWS dans les variables d’environnement EC2
  2. Créer un utilisateur IAM dédié et coder les credentials dans l’application
  3. Attacher un rôle IAM à l’instance EC2 avec les permissions S3 nécessaires  ✓
  4. Rendre le bucket S3 public

Explication : Les rôles IAM attachés aux instances EC2 sont le mécanisme le plus sécurisé : les credentials sont temporaires, rotés automatiquement par AWS, et jamais exposés dans le code ou les variables d’environnement. Les access keys statiques (A, B) sont un risque de sécurité majeur si exposées.

❓ Une entreprise veut utiliser Machine Learning sur AWS sans gérer d’infrastructure. Quelle combinaison de services est la plus adaptée ?

  1. EC2 GPU instances + TensorFlow installé manuellement
  2. Amazon SageMaker pour l’entraînement et le déploiement  ✓
  3. AWS Glue + Athena
  4. Amazon EMR + Spark MLlib

Explication : SageMaker est le service managé AWS pour le ML de bout en bout — préparation des données, entraînement, déploiement, monitoring. Sans infrastructure à gérer. EC2 + TensorFlow (A) nécessite de gérer l’infrastructure. Glue + Athena (C) est pour l’analytique, pas le ML. EMR + Spark MLlib (D) nécessite de gérer un cluster.

❓ Une application génère des millions d’événements par jour qui doivent être analysés en temps réel. Quel service AWS est le plus adapté ?

  1. Amazon SQS
  2. Amazon Kinesis Data Streams  ✓
  3. Amazon S3 + AWS Glue
  4. Amazon DynamoDB Streams

Explication : Kinesis Data Streams est conçu pour l’ingestion et l’analyse de données en temps réel à grande échelle. SQS (A) est une file de messages pour le découplage, pas l’analyse temps réel. S3 + Glue (C) est pour le batch, pas le temps réel. DynamoDB Streams (D) capture les modifications DynamoDB, pas les événements d’applications génériques.

❓ Une entreprise veut connecter son datacenter on-premise à AWS avec une latence prévisible et une bande passante dédiée. Quelle solution choisir ?

  1. VPN Site-to-Site
  2. AWS Direct Connect  ✓
  3. AWS Transit Gateway
  4. VPC Peering

Explication : AWS Direct Connect est une connexion réseau dédiée entre le datacenter et AWS, qui offre une latence stable et prévisible et une bande passante garantie. VPN Site-to-Site (A) passe par Internet — latence variable. Transit Gateway (C) connecte des VPCs entre eux, pas des datacenters. VPC Peering (D) connecte deux VPCs, pas un datacenter.

❓ Un architecte doit concevoir une solution de cache pour réduire la charge sur une base de données RDS MySQL avec des requêtes de lecture répétitives. Quelle est la meilleure approche ?

  1. Augmenter la taille de l’instance RDS
  2. Ajouter des Read Replicas RDS
  3. Déployer Amazon ElastiCache for Redis devant RDS  ✓
  4. Migrer vers DynamoDB

Explication : ElastiCache for Redis met en cache les résultats des requêtes fréquentes en mémoire — les lectures répétitives ne touchent plus RDS. Augmenter l’instance (A) aide mais ne résout pas le problème des requêtes répétitives. Les Read Replicas (B) répartissent les lectures mais ne cachent pas les données. Migrer vers DynamoDB (D) est une refactorisation majeure non justifiée.

❓ Une entreprise doit chiffrer des données dans S3 en utilisant ses propres clés de chiffrement qu’elle contrôle entièrement et qu’elle stocke dans AWS. Quelle option choisir ?

  1. SSE-S3 (chiffrement géré par AWS)
  2. SSE-KMS avec Customer Managed Key (CMK)  ✓
  3. SSE-C (clés fournies par le client)
  4. CSE (chiffrement côté client)

Explication : SSE-KMS avec CMK permet de créer et contrôler entièrement ses propres clés dans AWS KMS, avec audit dans CloudTrail. SSE-S3 (A) = AWS gère les clés, pas vous. SSE-C (C) = vous fournissez la clé à chaque requête mais AWS ne la stocke pas — vous devez la gérer vous-même côté client. CMK est le meilleur équilibre entre contrôle et facilité.

❓ Une application Lambda est appelée par API Gateway. Le temps de réponse est lent pour les premiers appels après une période d’inactivité. Quelle est la cause et la solution ?

  1. Lambda est limité en bande passante — augmenter la mémoire
  2. Lambda Cold Start — utiliser Provisioned Concurrency  ✓
  3. API Gateway n’est pas configuré pour le caching — activer le cache API Gateway
  4. La région est trop éloignée — utiliser CloudFront

Explication : Le Cold Start Lambda se produit quand une fonction n’a pas été utilisée récemment et qu’AWS doit initialiser l’environnement d’exécution. Provisioned Concurrency maintient des instances Lambda prêtes (préchauffées) en permanence, éliminant les cold starts. Le cache API Gateway (C) aide pour les réponses identiques mais ne résout pas le cold start.

❓ Une entreprise veut analyser des données dans S3 avec du SQL sans charger les données dans une base de données. Quel service AWS utiliser ?

  1. Amazon RDS
  2. Amazon Redshift
  3. Amazon Athena  ✓
  4. Amazon DynamoDB

Explication : Athena permet d’exécuter des requêtes SQL directement sur les données dans S3, sans infrastructure à provisionner. Facturation à la quantité de données scannées. RDS (A) et DynamoDB (D) nécessitent d’importer les données. Redshift (B) est un data warehouse performant mais nécessite de charger les données.

❓ Quelle est la différence entre une politique IAM basée sur l’identité et une politique basée sur les ressources pour S3 ?

  1. Il n’y a aucune différence fonctionnelle
  2. Les politiques basées sur les identités permettent l’accès inter-comptes, les Resource Policies non
  3. Les Resource Policies sont attachées directement au bucket S3 et peuvent accorder l’accès cross-account sans que la cible assume un rôle  ✓
  4. Les politiques basées sur les identités sont plus sécurisées

Explication : Les Resource Policies (politiques de bucket S3) peuvent accorder directement l’accès à d’autres comptes AWS sans que ces comptes aient besoin d’assumer un rôle IAM. C’est un avantage pour simplifier l’accès cross-account. Les politiques d’identité définissent ce qu’un utilisateur/rôle peut faire.

❓ Une entreprise a des charges de travail de calcul intensif (HPC, ML training) qui peuvent être interrompues. Quelle combinaison EC2 est la plus rentable ?

  1. On-Demand Instances + Placement Groups
  2. Spot Instances + Auto Scaling avec Spot Fleet  ✓
  3. Reserved Instances + Dedicated Hosts
  4. On-Demand + Reserved mix

Explication : Pour les charges tolérantes aux interruptions (HPC, ML training), Spot Instances offrent jusqu’à 90% d’économie. Spot Fleet gère automatiquement plusieurs pools de Spot Instances pour maximiser la capacité disponible et minimiser les interruptions. L’Auto Scaling complète avec On-Demand si les Spots ne sont pas disponibles.

5. Suggestion de Planning de préparation — 12 semaines

Ce planning suppose que vous avez le Cloud Practitioner ou une expérience AWS équivalente. Si vous débutez complètement, ajoutez 4 à 6 semaines pour les bases.

Semaine

Focus

Actions concrètes

Livrable

S1

Well-Architected Framework + IAM avancé

Lire les 5 piliers · IAM policies, rôles, cross-account · Lab : politiques IAM complexes

IAM Lab complet

S2

VPC approfondi — Sécurité réseau

VPC peering, Transit Gateway, PrivateLink · Security Groups vs NACLs · NAT Gateway vs NAT Instance · Lab : VPC complet avec public/privé

Architecture VPC documentée

S3

Chiffrement, Secrets, Services sécurité

KMS, Secrets Manager, SSM · WAF, Shield, GuardDuty, Macie · IAM Access Analyzer · Examen blanc Domaine 1

Score D1 >70%

S4

Résilience — HA et Disaster Recovery

RTO/RPO · Stratégies DR (Backup, Pilot Light, Warm Standby, Active-Active) · RDS Multi-AZ vs Read Replicas

Tableau DR mémorisé

S5

Auto Scaling + ELB + Bases de données

ASG policies · ALB vs NLB vs GWLB · Aurora vs RDS · DynamoDB Global Tables · ElastiCache Redis vs Memcached

Lab : ALB + ASG + RDS Multi-AZ

S6

Performance — Stockage et cache

S3 classes de stockage, lifecycle · EBS gp3 vs io2 · EFS vs FSx · ElastiCache · CloudFront vs Global Accelerator

Lab : CloudFront + S3

S7

Serverless, messaging, architecture event-driven

Lambda concurrency, cold starts · API Gateway · SQS FIFO vs Standard · SNS fan-out · EventBridge · Step Functions

Lab : serverless complet (Lambda+API GW+DynamoDB)

S8

Coûts — EC2, S3, FinOps

Modèles de tarification EC2 · S3 Intelligent-Tiering, lifecycle · Cost Explorer, Budgets, Trusted Advisor, Compute Optimizer

Plan FinOps simulé

S9

Architectures hybrides + Migration

Direct Connect vs VPN · Storage Gateway · AWS Migration Hub · Database Migration Service (DMS) · Application Migration Service

Schéma architecture hybride

S10

Patterns d’architecture + Services avancés

Architecture 3-tiers, serverless, data lake · Kinesis · Athena · Glue · Redshift · AppSync

5 patterns documentés

S11

Révision globale + Examens blancs

2 examens blancs complets (TutorialsDojo) · Identifier domaines faibles · Révision ciblée · Examen pratique officiel AWS

Score >75% stable

S12

Sprint final + Passage de l’examen

Révision légère (pas de nouveau contenu) · 1 examen blanc final · Passer le SAA-C03 ! · Mettre à jour LinkedIn

✅ SAA-C03 obtenu

 

6. Le jour de l’examen

Les mots-clés qui orientent la réponse — SAA-C03

Si la question dit…

Pensez à…

Service/Pattern probable

“hautement disponible” + “plusieurs AZ”

Multi-AZ, failover automatique

RDS Multi-AZ, ALB + ASG multi-AZ, Aurora

“sans gérer de serveurs” / “serverless”

Lambda, DynamoDB, API Gateway

Lambda + API GW + DynamoDB ou S3

“RTO/RPO très faibles” + “coût élevé acceptable”

Active-Active multi-région

Route 53 + Aurora Global + DynamoDB Global Tables

“le moins cher” + “tolérant aux interruptions”

Spot Instances

Spot Fleet + Auto Scaling

“lecture intensive” + “réduire charge BDD”

Cache ou Read Replicas

ElastiCache Redis ou RDS Read Replicas

“contenu mondial” + “latence faible” + “cache”

CDN

CloudFront

“routage réseau optimisé” + “IP statique”

Pas un CDN

Global Accelerator

“traitement en ordre exact” + “une seule fois”

FIFO, exactly-once

SQS FIFO Queue

“latence prévisible” + “datacenter connecté”

Connexion dédiée

AWS Direct Connect

“accès S3 privé depuis VPC”

Pas par Internet

VPC Gateway Endpoint pour S3

“plusieurs comptes AWS” + “facturation unique”

Multi-account management

AWS Organizations + Consolidated Billing

“qui a fait quoi” + “audit”

Journalisation des API

AWS CloudTrail

“détecter les menaces” + “comportements anormaux”

Détection ML automatique

Amazon GuardDuty

7. Ressources complémentaires

Ressources proposées par LeCloudFacile.com

•       Cours de préparation à la certification Solutions Architect Associate : formation vidéo complète et classé best-seller.

•       Learning Path Certification Architect AWS : parcours complet pour devenir Architect AWS certifié.

•      Coaching AWS Solutions Architect Associate : un accompagnement complet de plusieurs semaines par des experts certifiés

Dernier conseil : Le SAA-C03 récompense la compréhension des compromis — pourquoi une architecture est meilleure qu’une autre dans un contexte donné. Entraînez-vous à identifier les contraintes de chaque question (RTO, coût, équipe, connexion, charge) et à les faire correspondre aux services AWS. Lisez toujours jusqu’à la dernière ligne de l’énoncé — c’est souvent là que se cache la contrainte décisive.

Tags :