Un sito web esegue un web tier (gruppo EC2 Auto Scaling su due AZ) e un DB tier (RDS per MySQL Multi-AZ). Le ACL di rete delle sottoreti del database sono limitate solo alle sottoreti web che necessitano dell'accesso al DB; le sottoreti web utilizzano le regole NACL predefinite. Recentemente è stata aggiunta una terza sottorete al gruppo Auto Scaling. Dopo lo scaling, alcuni utenti riscontrano errori intermittenti che indicano che il server web non riesce a connettersi al database. Le tabelle di routing e i gruppi di sicurezza sono stati verificati. Quali modifiche dovrebbe apportare un amministratore SysOps affinché i server web nella nuova sottorete possano raggiungere l'istanza DB? (Scegliere due.)

Il problema si verifica perché le Network ACL (NACL) sono stateless e non consentono automaticamente il traffico di ritorno o il traffico da nuove sottoreti. Le NACL delle sottoreti del database erano state configurate per consentire l'accesso solo dalle sottoreti web originali. Quando è stata aggiunta una terza sottorete al gruppo Auto Scaling, le istanze EC2 in questa nuova sottorete non potevano connettersi al database perché le NACL del database non avevano regole che consentissero il traffico in entrata da questa nuova sottorete. Per risolvere il problema, è necessario aggiungere due regole alle NACL delle sottoreti del database: 1. Una regola di "Allow" in entrata per la porta MySQL (3306) con la sorgente impostata sulla nuova sottorete web. Questo permette alle istanze web di iniziare la connessione al database. 2. Una regola di "Allow" in uscita per l'intervallo di porte TCP effimere (1024-65535) con la destinazione impostata sulla nuova sottorete web. Questo permette al database di inviare risposte alle istanze web. Le opzioni che suggeriscono modifiche alle NACL predefinite delle sottoreti web sono errate perché il problema non risiede nella configurazione delle NACL web, ma in quelle del database che non riconoscono la nuova sottorete.