Un'azienda sta implementando un'applicazione web stateless su istanze EC2 in sottoreti private dietro un Application Load Balancer (ALB). Le istanze dell'applicazione web sono eseguite in un gruppo Auto Scaling. Un'applicazione di gestione stateful separata è eseguita su EC2 in un altro gruppo Auto Scaling. L'azienda desidera utilizzare lo stesso URL, hostname, porta e protocollo per entrambe le applicazioni, con l'applicazione di gestione accessibile sotto il prefisso di percorso /management. L'accesso all'interfaccia di gestione deve essere limitato agli intervalli IP on-premises dell'azienda. Un certificato SSL/TLS ACM proteggerà l'applicazione web. Quali due azioni dovrebbe intraprendere un ingegnere di rete per soddisfare questi requisiti? (Scegli due.)

La prima azione corretta è inserire una nuova regola nel listener HTTPS dell'ALB. Questa regola deve avere due condizioni: una path-pattern per /management per instradare le richieste all'applicazione di gestione e una source-ip per gli intervalli IP on-premises per limitare l'accesso. Se entrambe le condizioni sono soddisfatte, le richieste vengono inoltrate al target group dell'applicazione di gestione. Abilitare la stickiness per questo target group è fondamentale perché l'applicazione di gestione è stateful. La seconda azione corretta è configurare la regola predefinita del listener HTTPS per inoltrare tutte le altre richieste (quelle che non corrispondono alla regola /management) al target group dell'applicazione web. Poiché l'applicazione web è stateless, la stickiness deve essere disabilitata per il suo target group, garantendo una distribuzione uniforme del carico tra le istanze. Le opzioni errate propongono di modificare la regola predefinita per l'applicazione di gestione (che dovrebbe essere una regola separata), di usare X-Forwarded-For per il controllo IP (meno affidabile di source-ip per la sicurezza), o di inoltrare tutte le richieste a un solo target group, il che non soddisfa i requisiti di routing separato.