Een organisatie gebruikt AWS Organizations met een root OU en een child OU. De SCP van de root OU staat alle acties op alle resources toe. De SCP van de child OU staat alle DynamoDB- en Lambda-acties toe en weigert alle andere acties. Er is een account genaamd vendor-data in de child OU. Een IAM-gebruiker in dat account heeft het AdministratorAccess IAM-beleid, maar ontvangt AccessDenied bij een poging om een EC2-instance te starten. Welke wijziging moet worden aangebracht zodat de IAM-gebruiker EC2-instances kan starten in het vendor-data-account?

De correcte optie is om de SCP van de child OU te wijzigen om ook alle EC2-acties toe te staan. Service Control Policies (SCP's) zijn een krachtig mechanisme in AWS Organizations om de maximale beschikbare permissies voor accounts te beheren. SCP's zijn impliciet deny en werken als een allow-list wanneer ze worden toegepast. Een expliciete deny in een SCP overschrijft altijd een allow. In dit geval staat de SCP van de root OU alles toe, maar de SCP van de child OU staat alleen DynamoDB- en Lambda-acties toe en weigert alle andere acties. Dit betekent dat zelfs met het AdministratorAccess IAM-beleid, de IAM-gebruiker geen EC2-instances kan starten omdat de SCP van de child OU dit expliciet weigert. Door de SCP van de child OU aan te passen, worden de benodigde EC2-permissies toegevoegd. Het koppelen van het AmazonEC2FullAccess IAM-beleid aan de IAM-gebruiker is niet voldoende, omdat SCP's de maximale permissies bepalen, ongeacht de IAM-beleidsregels. Het maken van een nieuwe SCP en deze koppelen aan het vendor-data-account is niet mogelijk; SCP's kunnen alleen aan OU's of de root worden gekoppeld, niet aan individuele accounts. Het koppelen van een nieuwe SCP aan de root OU zou geen effect hebben, omdat de SCP van de child OU nog steeds de EC2-acties zou weigeren.