Organizacja używa AWS Organizations do zarządzania wieloma kontami. Polityka bezpieczeństwa wymaga oznaczania wszystkich niezaszyfrowanych woluminów Amazon EBS jako niezgodnych. Inżynier DevOps musi wdrożyć zautomatyzowaną, zawsze obecną kontrolę zgodności. Które podejście to osiągnie?

Prawidłowa odpowiedź to utworzenie reguły organizacyjnej AWS Config i wdrożenie jej za pomocą AWS CLI, a następnie zastosowanie SCP, aby zapobiec modyfikacjom AWS Config. Reguły organizacyjne AWS Config pozwalają na centralne zarządzanie zgodnością na wszystkich kontach w AWS Organizations, automatycznie sprawdzając, czy woluminy EBS są zaszyfrowane. SCP (Service Control Policies) zapewniają, że nikt nie wyłączy ani nie usunie AWS Config, gwarantując ciągłość kontroli zgodności. Pozostałe opcje są mniej efektywne lub nie spełniają wszystkich wymagań: Szablon CloudFormation z regułą AWS Inspector nie jest idealnym rozwiązaniem do centralnego zarządzania zgodnością w całej organizacji, a AWS Inspector nie jest przeznaczony do sprawdzania szyfrowania EBS. SCP zapobiegające uruchamianiu instancji bez szyfrowania EBS jest dobrym rozwiązaniem prewencyjnym, ale nie oznacza istniejących, niezgodnych zasobów jako niezgodnych. Analiza CloudTrail jest reaktywna, a nie proaktywna. Wdrożenie roli IAM i potoku CodePipeline z Lambda jest złożonym i reaktywnym podejściem, które wymaga pisania niestandardowego kodu i nie oferuje wbudowanej funkcji raportowania zgodności jak AWS Config.