Architekt rozwiązań projektuje VPC z wieloma podsieciami do hostowania instancji EC2 i instancji Amazon RDS DB. VPC ma sześć podsieci w dwóch strefach dostępności: w każdej strefie dostępności znajduje się podsieć publiczna, podsieć prywatna i podsieć dedykowana dla bazy danych. Tylko instancje EC2 w podsieciach prywatnych powinny mieć dostęp do baz danych RDS. Które rozwiązanie wymusza ten wymóg?

Poprawna odpowiedź to utworzenie grupy zabezpieczeń, która zezwala na ruch przychodzący z grupy zabezpieczeń przypisanej do instancji w podsieciach prywatnych i dołączenie jej do instancji DB. Grupy zabezpieczeń działają jak wirtualne firewalle dla instancji, kontrolując ruch przychodzący i wychodzący. Określając jako źródło inną grupę zabezpieczeń, zapewniamy, że tylko instancje należące do tej grupy (w tym przypadku instancje EC2 w podsieciach prywatnych) mogą nawiązywać połączenia z bazą danych. Pozostałe opcje są nieprawidłowe: Tworzenie nowej tabeli routingu wykluczającej bloki CIDR podsieci publicznych nie ograniczy dostępu na poziomie instancji, a jedynie wpłynie na routing pakietów, co nie jest mechanizmem kontroli dostępu. Grupa zabezpieczeń odrzucająca ruch z podsieci publicznych jest niepotrzebna, ponieważ domyślnie ruch jest odrzucany, chyba że zostanie jawnie dozwolony. Ważniejsze jest zezwolenie na ruch z odpowiednich źródeł. Połączenia peeringowe służą do łączenia VPC lub podsieci, ale nie są mechanizmem kontroli dostępu na poziomie instancji.