Een retailer draait zijn e-commerce-app op EC2-instances achter een Application Load Balancer (ALB) met een Amazon RDS-backend. CloudFront is geconfigureerd met de ALB als origin om statische content te cachen. Route 53 host publieke DNS. Na een app-update retourneert de ALB soms HTTP 502 (Bad Gateway) vanwege verkeerd geformatteerde HTTP-headers die naar de ALB worden teruggestuurd. Het onmiddellijk opnieuw laden van de pagina lukt meestal wel. Terwijl het bedrijf de hoofdoorzaak oplost, moet de solutions architect een aangepaste foutpagina tonen in plaats van de standaard ALB-foutpagina, met minimale operationele overhead. Welke combinatie van stappen bereikt dit? (Kies twee.)

De correcte stappen zijn: 1. Maak een Amazon S3-bucket aan die is geconfigureerd voor statische websitehosting en upload de aangepaste foutpagina('s). 2. Configureer CloudFront custom error responses en specificeer de aangepaste foutpagina. CloudFront kan aangepaste foutpagina's weergeven voor specifieke HTTP-statuscodes. Door een S3-bucket te gebruiken voor statische websitehosting, kan de aangepaste foutpagina eenvoudig worden gehost en toegankelijk worden gemaakt voor CloudFront. Wanneer de ALB een 502-fout retourneert, vangt CloudFront deze op en toont het de geconfigureerde aangepaste foutpagina vanuit S3. Dit minimaliseert operationele overhead omdat er geen wijzigingen aan de ALB of de applicatie zelf nodig zijn. De andere opties zijn minder geschikt: CloudWatch-alarmen met Lambda-functies om ALB-regels aan te passen, introduceren complexiteit en operationele overhead, en zijn niet de meest directe oplossing voor het weergeven van een aangepaste foutpagina. Route 53 health checks en fallback targets zijn nuttig voor het omleiden van verkeer bij een volledige storing, maar niet voor het afhandelen van specifieke HTTP-fouten van de ALB, vooral als de pagina bij herladen wel werkt.