A company has a web application that runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The instances are in an Auto Scaling group. The ALB is associated with an HTTPS listener…

Question

Options

• AUse AWS Private Certificate Authority to create a new certificate that covers all the required
• BCreate a new ACM certificate that covers the new domain. Add the new certificate to the HTTPS
• CUpload a new certificate that covers all domains to AWS Identity and Access Management (IAM).
• DCreate a new ACM certificate that covers the new domain. Create a new listener over a secure

• A
  6% (1)
• B
  65% (11)
• C
  12% (2)
• D
  18% (3)

Explanation

Option B is correct because ALB supports Server Name Indication (SNI), which allows multiple ACM certificates to be associated with a single HTTPS listener - so you simply create a new ACM certificate for the new domain and attach it to the existing listener, then add a host-based routing rule to direct traffic to the new target group. This reuses all existing infrastructure with minimal changes.

Option A is wrong because AWS Private CA issues private certificates not trusted by public browsers, making it unsuitable for a public-facing web application. Option C is wrong because uploading certificates to IAM is a legacy approach with significantly more operational overhead (manual renewal, CLI uploads) compared to ACM's automated renewal. Option D is wrong because you cannot create a second HTTPS listener on port 443 for the same ALB - a new listener would require a non-standard port, which defeats the purpose of transparent HTTPS access.

Memory tip: Think "SNI = multiple certs, one listener." Whenever you see a scenario involving a new domain on an existing ALB without wildcards, SNI via ACM on the existing listener is almost always the least-overhead answer.

No community discussion yet for this question.