Fabrikam Games pozwala swojej grupie DevOps tworzyć role IAM dla obciążeń EC2. Dział bezpieczeństwa musi zapewnić, że każda tworzona przez nich rola nie może przekroczyć zdefiniowanego zestawu uprawnień (tylko do odczytu tabeli DynamoDB Scores i publikowania do CloudWatch Logs), niezależnie od tego, jakie polityki DevOps dołączy później. Jakie jest NAJSKUTECZNIEJSZE podejście?

Poprawna odpowiedź jest najskuteczniejsza, ponieważ używa granicy uprawnień (permissions boundary) do zdefiniowania maksymalnych uprawnień, jakie może mieć rola. Dołączenie polityki IAM do grupy DevOps z warunkiem iam:PermissionsBoundary wymusza, aby każda tworzona lub aktualizowana rola miała tę konkretną granicę uprawnień. To gwarantuje, że nawet jeśli DevOps dołączy inne polityki do roli, efektywne uprawnienia nigdy nie przekroczą uprawnień zdefiniowanych w granicy. Pierwsza opcja jest nieprawidłowa, ponieważ granice uprawnień użytkowników wpływają tylko na uprawnienia samego użytkownika, a nie na uprawnienia ról, które ten użytkownik tworzy. Trzecia opcja jest nieprawidłowa, ponieważ SCP (Service Control Policies) działają na poziomie konta lub jednostki organizacyjnej i ograniczają maksymalne uprawnienia dla wszystkich podmiotów w danym zakresie, co jest zbyt szerokie i nie pozwala na precyzyjne zarządzanie uprawnieniami poszczególnych ról tworzonych przez DevOps. Czwarta opcja jest nieprawidłowa, ponieważ polityki zasobów DynamoDB kontrolują dostęp do samej tabeli, a nie do uprawnień, jakie role mogą posiadać.