1.4 - Gouvernance et partage multi-comptes (Organizations, SCP, RAM, StackSets)

1. Une entreprise veut une gouvernance centrale pour qu'aucun compte membre, même son utilisateur root, ne puisse quitter AWS Organizations ni désactiver CloudTrail. Quel contrôle impose cela sur tous les comptes ?

• Une permissions boundary attachée à chaque rôle IAM de chaque compte membre
• Une service control policy (SCP) appliquée à la racine de l'organisation ou à une OU (bonne réponse)
• Une politique IAM basée sur l'identité poussée dans chaque compte par IAM Identity Center
• Une politique de ressource sur le bucket du trail CloudTrail de l'organisation

Les SCP fixent les permissions maximales des comptes membres et bornent même l'utilisateur root ; refuser leave-organization et cloudtrail:StopLogging à la racine/OU bloque donc tout le monde. Les permissions boundaries et politiques d'identité ne contraignent pas le root, et une politique de bucket n'arrête pas le trail lui-même.

2. Une entreprise veut un environnement multi-comptes prêt à l'emploi avec une OU de sécurité, un compte d'archivage des logs centralisé, un compte d'audit et du SSO via IAM Identity Center, déployé rapidement selon les bonnes pratiques AWS. Quel service met en place cette landing zone ?

• AWS Control Tower (bonne réponse)
• AWS Organizations configuré entièrement à la main avec des SCP sur mesure et sans baseline
• Des agrégateurs AWS Config déployés un par un dans chaque compte de l'entreprise
• Un CloudFormation StackSet qui construit chaque compte et contrôle à partir de zéro

Control Tower orchestre une landing zone conforme aux bonnes pratiques : Organizations, une OU de sécurité, les comptes log-archive et audit, IAM Identity Center et des guardrails, en quelques clics. Le faire à la main avec Organizations, Config ou un StackSet reproduit les briques mais reste lent, source d'erreurs et non géré.

3. Dans AWS Control Tower, quelle affirmation associe correctement les types de guardrails au mécanisme qui les applique ?

• Les guardrails préventifs utilisent des SCP ; les détectifs utilisent des règles AWS Config (bonne réponse)
• Les guardrails préventifs utilisent des règles AWS Config, et les détectifs utilisent des SCP appliquées à la racine de l'organisation
• Les guardrails préventifs et détectifs sont implémentés exclusivement avec des service control policies attachées par OU
• Les guardrails préventifs et détectifs reposent uniquement sur les résultats d'Amazon GuardDuty et d'AWS Security Hub

Les guardrails préventifs bloquent les actions interdites via des SCP ; les détectifs vérifient en continu la non-conformité via des règles AWS Config. Inverser les deux est faux, et aucun type ne repose uniquement sur des SCP ni sur GuardDuty/Security Hub.

4. Une équipe plateforme doit déployer automatiquement des ressources de base personnalisées (rôles IAM, VPC flow logs) et des SCP supplémentaires vers chaque compte, nouveau ou existant, géré par Control Tower, à l'aide de leur propre CloudFormation. Quelles DEUX approches conviennent ? (Choisissez DEUX réponses.)

• Utiliser Customizations for AWS Control Tower (CfCT) lié au cycle de vie des comptes (bonne réponse)
• Déployer les ressources avec des StackSets service-managed ciblant les OU de l'organisation (bonne réponse)
• Exécuter manuellement chaque modèle CloudFormation dans la console de chaque compte après son provisioning par Account Factory, puis répéter pour tous les futurs comptes
• Désactiver Control Tower et tout gérer depuis une unique stack monolithique

CfCT branche des modèles CloudFormation et des SCP personnalisés sur le cycle de vie des comptes Control Tower, pour les appliquer aux comptes nouveaux et existants. Les StackSets service-managed ciblant les OU se déploient automatiquement à mesure que les comptes rejoignent. Les exécutions manuelles par compte ne passent pas à l'échelle, et désactiver Control Tower supprime la gouvernance requise.

5. Quelle fonctionnalité de Control Tower permet à des utilisateurs autorisés de provisionner de nouveaux comptes AWS via une configuration standardisée et pré-approuvée (baseline réseau, guardrails) exposée via Service Catalog ?

• Account Factory (bonne réponse)
• Un runbook maintenu à la main et stocké dans le wiki Confluence interne de l'entreprise
• L'API CreateAccount d'AWS Organizations invoquée directement par chaque équipe demandeuse
• Des permission sets IAM Identity Center affectés au compte nouvellement créé

Account Factory est la capacité de Control Tower, livrée via Service Catalog, qui provisionne de nouveaux comptes avec une baseline standardisée et des guardrails déjà appliqués. Un runbook ou un simple appel CreateAccount saute la baseline, et les permission sets donnent l'accès mais ne provisionnent pas de comptes.

6. Un compte reseau possede un Transit Gateway et des sous-reseaux auxquels les comptes applicatifs doivent se rattacher et deployer, sans copier les ressources reseau dans chaque compte. Quelles DEUX actions Resource Access Manager le permettent ? (Choisissez DEUX reponses.)

• Partager le Transit Gateway aux comptes applicatifs via RAM (bonne réponse)
• Accorder a chaque compte applicatif un role administrateur complet sur l'ensemble du compte reseau central
• Recreer tous les sous-reseaux dans chaque compte applicatif en utilisant des plages CIDR identiques qui se chevauchent
• Partager les sous-reseaux du VPC pour que les comptes applicatifs y lancent des ressources (bonne réponse)

RAM partage des ressources precises entre comptes : partager le Transit Gateway permet aux comptes applicatifs de creer des rattachements, et partager les sous-reseaux (VPC sharing) leur permet de lancer des instances directement dans le VPC central, le tout appartenant au compte reseau. Un acces admin complet est excessif et peu sur, et recreer les sous-reseaux annule la propriete centralisee et peut creer des chevauchements.