locks.canal.example must present a trusted certificate to browsers on App Service. What should the security engineer implement for TLS on the app?
Select an answer to reveal the explanation.
Short Explanation
Point the custom hostname at App Service and hang a real cert on it—managed cert or one the app references. VNet integration and an empty Key Vault don’t put TLS on the public hostname.
Full Explanation
Browsers reaching locks.canal.example on App Service need a custom-domain binding plus a trusted TLS certificate on the app—either an App Service managed certificate or a certificate the app references (commonly from Key Vault). That platform binding is what presents a trusted chain to visitors for the canal hostname.
Configuring only App Service regional VNet integration and skipping custom-domain certificate binding fails by concept: VNet integration addresses private outbound/inbound patterns, not public custom-domain TLS presentation. Rewriting the site in Kestrel with custom code TLS termination fails by concept: that is application-code concern (AZ-204 style), not the App Service custom-domain/certificate binding skill. Creating an empty Key Vault with no app binding fails by concept: vault existence alone does not complete hostname or certificate binding on App Service.
Exam caveat: custom domain + certificate binding on App Service is the public TLS task; Key Vault is optional sourcing, not the finish line by itself. Operational check: add locks.canal.example, bind a valid certificate, confirm HTTPS shows a trusted chain in the browser, and verify HTTP-to-HTTPS behavior aligns with HTTPS Only settings.