Strona internetowa korzysta z warstwy sieciowej (grupa Auto Scaling EC2 w dwóch strefach dostępności) i warstwy bazy danych (RDS dla MySQL Multi-AZ). Listy kontroli dostępu do sieci (NACL) podsieci bazy danych są ograniczone tylko do podsieci sieciowych, które potrzebują dostępu do bazy danych; podsieci sieciowe używają domyślnych reguł NACL. Niedawno dodano trzecią podsieć do grupy Auto Scaling. Po skalowaniu, niektórzy użytkownicy sporadycznie widzą błędy, że serwer sieciowy nie może połączyć się z bazą danych. Tabele routingu i grupy bezpieczeństwa zostały zweryfikowane. Jakie zmiany powinien wprowadzić administrator SysOps, aby serwery sieciowe w nowej podsieci mogły uzyskać dostęp do instancji bazy danych? (Wybierz dwie odpowiedzi.)

Poprawne odpowiedzi rozwiązują problem, ponieważ NACL są bezstanowe i wymagają zarówno reguł ruchu przychodzącego, jak i wychodzącego dla dwukierunkowej komunikacji. Kiedy nowa podsieć została dodana do grupy Auto Scaling, jej adres IP nie był uwzględniony w istniejących regułach NACL podsieci bazy danych. Aby serwery sieciowe w nowej podsieci mogły połączyć się z bazą danych, NACL podsieci bazy danych musi zezwalać na ruch przychodzący na porcie 3306 (MySQL) ze źródła nowej podsieci. Dodatkowo, aby baza danych mogła wysyłać odpowiedzi z powrotem do serwerów sieciowych, NACL podsieci bazy danych musi zezwalać na ruch wychodzący w efemerycznym zakresie portów TCP (1024-65535) do nowej podsieci. Pozostałe opcje są nieprawidłowe, ponieważ: Dodanie reguł do domyślnej NACL podsieci sieciowej nie pomoże, ponieważ problem dotyczy NACL podsieci bazy danych. Dodanie reguły ruchu wychodzącego dla MySQL/Aurora (3306) z podsieci bazy danych do nowej podsieci sieciowej jest nieprawidłowe, ponieważ baza danych odpowiada na efemerycznym porcie, a nie na porcie 3306.