AWS CloudOps Engineer - Associate (SOA-C03) — Questions d'entraînement et examen blanc

Raisonne à rebours à partir de ce que le scénario écarte déjà. L'accès général à internet prouve que le routage fonctionne. Les network access control lists sont ouvertes, donc le sous-réseau ne filtre rien. La politique du bucket S3 autorise l'accès depuis le VPC, et c'est là l'indice, car une politique rédigée ainsi n'est satisfaite que lorsque la requête arrive effectivement par le chemin de l'endpoint privé. Le trafic qui sort via une NAT gateway atteint l'endpoint public de S3 et ne porte aucun contexte d'endpoint : la politique le refuse donc, même si les paquets arrivent bien.

C'est ce qui fait du VPC endpoint pour S3 l'élément à vérifier. Existe-t-il un gateway endpoint pour S3 dans ce VPC, et son association de table de routage inclut-elle le sous-réseau privé ? Créer l'endpoint ne représente que la moitié du travail ; tu dois ensuite l'ajouter comme cible dans la table de routage pour le trafic à destination de S3, et un sous-réseau dont la table de routage n'a jamais été associée continue d'emprunter le chemin internet.

Les trois autres ne collent pas aux symptômes. La bande passante de la NAT gateway provoquerait des lenteurs, pas un refus net. Le versioning du bucket est un réglage de protection des données, sans effet sur l'accès. La permission du rôle de l'instance est un piège qui sonne plausible, mais l'énoncé te dit que le contrôle en jeu est la politique du bucket.

Astuce d'examen : quand la connectivité fonctionne globalement et qu'un seul service échoue, cherche dans la politique de ressource une condition qui contraint le chemin, et pas seulement le principal.

Survivre à la perte d'une Availability Zone demande deux choses : une copie des données ailleurs, et quelque chose qui promeut cette copie automatiquement. Activer le cluster mode avec des réplicas répartis sur plusieurs Availability Zones fournit la copie, et la bascule automatique Multi-AZ fournit la promotion : elle détecte que le primaire est injoignable et élit un réplica dans une zone encore debout, sans opérateur dans la boucle. C'est pour cela que cette configuration améliore la tolérance aux pannes exactement dans le cas de panne décrit par le scénario.

Remarque la formulation prudente à propos de la perte de données. La réplication vers les réplicas est asynchrone : les écritures que le primaire a acquittées juste avant de tomber n'ont peut-être jamais atteint un réplica. Ce que l'on peut défendre, c'est une perte de données minimale, pas nulle, et une réponse qui promet zéro perte avec de la réplication asynchrone est généralement la mauvaise.

Les distracteurs échouent sur la disponibilité. Les snapshots quotidiens sont une sauvegarde, utile pour restaurer après une corruption, mais qui se mesure en heures de perte et en restauration manuelle. Des nœuds autonomes indépendants dans différentes zones ne partagent aucune donnée : en perdre un, c'est perdre toutes les sessions qui vivaient là. La persistance append-only sur un nœud unique survit au redémarrage du processus sur ce nœud, mais le nœud reste dans une seule zone et il n'y a rien vers quoi basculer.

Conseil d'examen : sépare la durabilité de la disponibilité. Les snapshots et la persistance donnent la durabilité ; les réplicas plus la promotion automatique donnent la disponibilité.

Appliquer une étiquette à une instance est un appel d'API, et c'est cet appel qui sert de crochet à toute l'automatisation. L'étiquetage passe par l'action CreateTags d'Amazon EC2, AWS CloudTrail journalise cet appel comme événement de gestion, CloudTrail livre les événements qu'il journalise à Amazon EventBridge, et une règle EventBridge dont le pattern d'événement correspond à cet appel d'API et à cette clé d'étiquette invoque AWS Lambda comme cible. La fonction Lambda crée ensuite le bucket S3 via le SDK. Rien n'interroge par polling, rien ne s'exécute sur minuterie, et la réaction se produit parce que l'appel d'API a eu lieu — c'est exactement ce que veut dire piloté par les événements.

Les trois autres combinaisons cassent dès leur première étape. Les métriques Amazon CloudWatch sont des séries temporelles numériques et aucune métrique ne porte une clé d'étiquette et sa valeur : rien dans cette chaîne ne peut donc détecter le changement, et placer Amazon SNS devant AWS Lambda ne fait que relayer une notification qui n'a jamais été générée. Une règle planifiée Amazon EventBridge qui interroge les étiquettes par polling est l'inverse du pilotage par les événements : elle se réveille sur minuterie, ajoute une latence pouvant aller jusqu'à l'intervalle de polling et tourne en permanence alors que rien n'a changé, si bien qu'AWS Step Functions derrière elle hérite de ce délai. L'option AWS Config est la plus proche d'être plausible, car AWS Config évalue effectivement les changements de configuration des ressources, mais passer par AWS Systems Manager et AWS CloudFormation pour créer un seul bucket, c'est une machinerie bien plus lourde que ce que le scénario demande, et cela abandonne la correspondance de pattern EventBridge, qui fait le vrai filtrage.

Conseil d'examen : pour une exigence de la forme quand ceci arrive, fais cela, la réponse AWS par défaut est CloudTrail enregistre l'appel d'API, EventBridge fait correspondre le pattern d'événement et Lambda exécute l'action. Reconnaître ce trio te permet de répondre du premier coup d'œil à la plupart des questions sur l'automatisation pilotée par les événements.

Lis les deux contraintes ensemble : le chiffrement en transit, et des certificats gérés par AWS. AWS Certificate Manager, ou ACM, provisionne des certificats publics, les valide et les renouvelle automatiquement, et ACM s'intègre à Elastic Load Balancing, si bien que tu peux déployer le certificat directement sur le load balancer. Tu attaches le certificat provisionné au listener HTTPS de l'ALB et la plateforme gère le reste du cycle de vie, sans matériel de clé à copier sur les instances et sans date de renouvellement à retenir.

Chaque distracteur casse l'une des contraintes. Les certificats auto-signés générés sur chaque instance avec OpenSSL ne sont pas gérés par AWS du tout, et les clients les rejettent tant que tu ne distribues pas la confiance à la main. AWS KMS crée et contrôle des clés cryptographiques ; ce n'est pas une autorité de certification et il ne génère pas de certificats TLS. Téléverser des certificats serveur IAM fonctionne encore pour d'anciennes configurations, mais ces certificats ont été obtenus ailleurs et le renouvellement t'incombe, ce qui est précisément la charge d'administration que la question te demande d'éviter.

Astuce d'examen : certificats gérés par AWS plus load balancer, c'est un couple fixe. Si une question ajoute ensuite le chiffrement entre le load balancer et les instances placées derrière, traite la connexion back-end comme une décision distincte du certificat du listener.