Firma uruchamia aplikację do pozyskiwania poufnych danych na wielu kontach AWS (w AWS Organizations). Instancje EC2 w grupach Auto Scaling używają niestandardowego AMI i nie mają dostępu do Internetu; wymagane punkty końcowe VPC są na swoim miejscu. Administratorzy potrzebują zautomatyzowanego, centralnie kontrolowanego dostępu do logowania się do instancji w celu konserwacji i rozwiązywania problemów, a zespół bezpieczeństwa musi być powiadamiany za każdym razem, gdy instancje są dostępne. Które rozwiązanie spełnia te wymagania?

Poprawna odpowiedź wykorzystuje EC2 Image Builder do zapewnienia, że niestandardowe AMI zawiera najnowszego agenta SSM, co jest kluczowe dla funkcjonalności Systems Manager. Dołączenie roli AmazonSSMManagedInstanceCore do instancji umożliwia im komunikację z usługą Systems Manager. Session Manager zapewnia bezpieczny, centralnie kontrolowany dostęp do instancji bez konieczności otwierania portów SSH/RDP ani dostępu do Internetu. Włączenie logowania sesji do S3 i skonfigurowanie powiadomień o zdarzeniach S3 do tematu SNS spełnia wymagania dotyczące audytu i powiadamiania zespołu bezpieczeństwa o każdym dostępie. Pozostałe opcje są nieprawidłowe, ponieważ: Opcja 1: EC2 Instance Connect wymaga otwartego portu SSH/RDP, a cfn-init nie jest odpowiednim narzędziem do zmiany tras VPC dla dostępu zewnętrznego. Opcja 2: Brama NAT i host bastionu wprowadzają dostęp do Internetu, co jest sprzeczne z wymaganiem braku dostępu do Internetu dla instancji. Haki cyklu życia Auto Scaling nie są przeznaczone do audytu logowań. Opcja 4: AWS Config służy do oceny zgodności zasobów, a nie do dołączania SCP. Systems Manager Automation może być użyty do wbudowania agenta SSM, ale Config jest tu niewłaściwy.