Een website draait een webtier (EC2 Auto Scaling group verdeeld over twee AZ's) en een DB-tier (RDS for MySQL Multi-AZ). De netwerk-ACL's van het databasesubnet zijn beperkt tot alleen de websubnetten die DB-toegang nodig hebben; de websubnetten gebruiken standaard NACL-regels. Onlangs is een derde subnet toegevoegd aan de Auto Scaling group. Na het schalen zien sommige gebruikers af en toe fouten dat de webserver geen verbinding kan maken met de database. Routetabellen en security groups zijn geverifieerd. Welke wijzigingen moet een SysOps-beheerder aanbrengen zodat webservers in het nieuwe subnet de DB-instantie kunnen bereiken? (Kies twee.)

De correcte antwoorden zijn "Voeg op de netwerk-ACL's die zijn gekoppeld aan de databasesubnetten een inkomende Allow-regel toe voor MySQL/Aurora (3306) met de bron ingesteld op het nieuwe websubnet" en "Voeg op de netwerk-ACL's die zijn gekoppeld aan de databasesubnetten een uitgaande Allow-regel toe voor het ephemeral TCP-poortbereik met de bestemming ingesteld op het nieuwe websubnet". Netwerk-ACL's zijn stateless, wat betekent dat zowel inkomende als uitgaande regels expliciet moeten worden gedefinieerd voor bidirectioneel verkeer. Wanneer een nieuw subnet wordt toegevoegd, moet de database-NACL worden bijgewerkt om inkomend verkeer op poort 3306 (MySQL) vanuit het nieuwe websubnet toe te staan en uitgaand verkeer op het ephemeral poortbereik (1024-65535) terug naar het nieuwe websubnet toe te staan. De andere opties zijn incorrect omdat ze ofwel de verkeerde richting, de verkeerde poorten, of de verkeerde NACL (standaard NACL van de websubnetten) aanpassen. De websubnetten gebruiken standaard NACL-regels, die al alle inkomende en uitgaande verkeer toestaan.