Inżynier sieci tworzy szablon uruchamiania (launch template) dla grupy Auto Scaling, która będzie uruchamiać urządzenie sieciowe z systemem Linux. Urządzenie potrzebuje podstawowego interfejsu sieciowego oraz drugiego interfejsu, który używa publicznego adresu IP (Elastic IP z puli BYOIP firmy) do ruchu aplikacyjnego do/z internetu. Które podejście implementuje ten projekt?

Poprawna odpowiedź zakłada, że szablon uruchamiania (launch template) może określać tylko jeden interfejs sieciowy, który staje się interfejsem podstawowym (eth0). Aby dodać drugi interfejs sieciowy i przypisać mu Elastic IP z puli BYOIP, należy użyć skryptu cloud-init uruchamianego przez user data. Skrypt ten może programowo utworzyć i dołączyć dodatkowy interfejs sieciowy (ENI) oraz powiązać z nim wcześniej zaalokowany Elastic IP. Pierwsza opcja jest niepoprawna, ponieważ szablon uruchamiania nie pozwala na bezpośrednie konfigurowanie wielu interfejsów sieciowych z różnymi ustawieniami podsieci i przypisywaniem BYOIP w ten sposób. Druga opcja jest niepoprawna, ponieważ automatyczne przypisywanie publicznych adresów IP nie pozwala na użycie Elastic IP z puli BYOIP. Trzecia opcja jest niepoprawna, ponieważ AWS Global Accelerator nie służy do przypisywania interfejsów sieciowych ani adresów IP do instancji EC2, a funkcja Lambda nie jest odpowiednim mechanizmem do bezpośredniego zarządzania interfejsami sieciowymi instancji w ten sposób.