1.3 - Principes de conception AWS et Cloud Adoption Framework
L'objectif 1.3 de l'AWS Certified Cloud Practitioner couvre les principes de conception cloud et l'accompagnement de l'adoption. L'Infrastructure as Code, via un service comme AWS CloudFormation, permet de déployer le même environnement de façon fiable et reproductible en le définissant dans des modèles plutôt qu'à la main dans la console. Le AWS Cloud Adoption Framework (CAF) organise l'accompagnement en six perspectives - métier, personnes, gouvernance, plateforme, sécurité et opérations - pour aider à planifier le parcours cloud. Un principe clé est de concevoir pour la panne et le couplage lâche : utiliser des composants découplés pour qu'une défaillance soit isolée plutôt que de se propager. Le coût total de possession (TCO) capture le coût complet de possession et d'exploitation d'un système, utile pour comparer le sur site au cloud. Attends-toi à des mises en situation demandant le bon principe ou cadre.
Environnements reproductibles depuis des modèles = Infrastructure as Code (CloudFormation). Accompagnement en six perspectives = CAF. Composants découplés pour isoler une panne = conception pour la panne/couplage lâche. Coût complet de possession + exploitation = TCO.
Questions d'entraînement
1. Quelle approche AWS permet de déployer le même environnement de façon fiable en le définissant en tant que code ?
- Infrastructure as Code (ex. AWS CloudFormation) (bonne réponse)
- Cliquer manuellement dans la console à chaque fois
- Envoyer un runbook par e-mail à un opérateur
- Restaurer une image de serveur physique
L'Infrastructure as Code (IaC) avec les modèles CloudFormation provisionne les ressources de façon cohérente et répétable, réduisant les erreurs manuelles.
2. Le AWS Cloud Adoption Framework (CAF) organise ses recommandations en combien de perspectives ?
- Trois
- Quatre
- Cinq
- Six (bonne réponse)
Le AWS CAF compte six perspectives : Métier, Personnes, Gouvernance (capacités métier) et Plateforme, Sécurité, Opérations (capacités techniques).
3. Quel énoncé reflète le mieux le principe cloud de conception pour la panne et du couplage lâche ?
- Exécuter un seul gros serveur pour simplifier la gestion
- Stocker tout l'état sur une seule instance
- Éviter l'automatisation pour réduire la complexité
- Utiliser des composants découplés pour isoler une panne (bonne réponse)
Le couplage lâche avec des services comme les files d'attente évite qu'une panne d'un composant se propage, améliorant la résilience et la scalabilité.
4. Quel terme décrit le coût total de possession et d'exploitation d'un système, utile pour comparer le sur site à AWS ?
- Retour sur investissement (ROI)
- Accord de niveau de service (SLA)
- Objectif de temps de reprise (RTO)
- Coût total de possession (TCO) (bonne réponse)
Le TCO capture tous les coûts directs et indirects (matériel, énergie, personnel, locaux) et sert à comparer l'exploitation sur site à AWS.
5. Une équipe DevOps veut créer des environnements de test identiques des dizaines de fois par semaine sans clics manuels dans la console. Quelle approche convient le mieux ?
- Demander à un admin de le construire à la main à chaque fois
- Définir l'infrastructure en code avec CloudFormation (bonne réponse)
- Restaurer une image de serveur physique à chaque fois
- Envoyer une liste de contrôle à un opérateur
L'Infrastructure as Code avec des modèles CloudFormation provisionne le même environnement de façon répétable et automatique, supprimant les clics manuels et les dérives de configuration.
6. Quel modèle de service offre le plus de contrôle sur le système d'exploitation pendant qu'AWS gère le matériel physique ?
- Software as a Service (SaaS)
- Function as a Service
- Infrastructure as a Service (IaaS) (bonne réponse)
- Base de données entièrement gérée
L'IaaS (ex. Amazon EC2) donne le contrôle de l'OS, du réseau et de l'exécution tandis qu'AWS gère le matériel. Le SaaS masque tout cela.