Technical Lab: Configure TLS Termination and End-to-End TLS Encryption
Questions
Question 1 — Multiple Choice
You are configuring an Azure Application Gateway to expose an internal web application. The security requirement determines that traffic between the gateway and backend servers must remain encrypted, but the certificate installed on the backends is self-signed and does not belong to a recognized public CA.
What is the correct configuration for the Application Gateway to accept this backend certificate without rejecting the connection?
A) Enable the "Use well-known CA certificate" option in the backend HTTP settings
B) Install the self-signed root certificate as a Trusted Root Certificate in the backend HTTP settings
C) Configure an HTTPS listener with the backend's self-signed certificate on the gateway frontend
D) Associate a custom SSL Policy that disables certificate chain verification on the backend
Question 2 — Technical Scenario
An engineer configured the Application Gateway with the following intended behavior: receive HTTPS connections from clients on port 443, decrypt traffic, inspect HTTP headers, and forward traffic to backends also on port 443 with new TLS encryption.
After deployment, logs show that the backend is receiving traffic on port 80 in clear text, contrary to the requirement.
Frontend listener : HTTPS / port 443
Backend setting : Protocol = HTTP, Port = 80
Backend pool : app-server-01:80
What is the direct cause of the observed behavior?
A) Application Gateway does not support re-encryption to backends on the same port as the listener
B) The Backend HTTP Setting was configured with HTTP protocol instead of HTTPS, disabling re-encryption
C) The SSL Policy applied to the listener prevents the outbound connection from using TLS
D) The backend pool points to port 80, which overrides the protocol defined in the Backend HTTP Setting
Question 3 — True or False
In Azure Application Gateway v2, when end-to-end TLS configuration is active and the backend server certificate is issued by a publicly trusted CA (recognized by the Mozilla Trusted CA Store), it is not necessary to manually upload any root or intermediate certificates in the backend HTTP settings for the TLS connection to be successfully established.
Question 4 — Technical Scenario
A team needs to use Azure Front Door to publish an API with the following requirements:
- External clients access via HTTPS with a custom domain
- Traffic between Front Door and the origin server must be encrypted
- The origin server certificate is managed internally and issued by a corporate private CA
After configuration, external client connections work, but Front Door returns a 502 error when trying to reach the origin.
What is the most likely cause?
A) Front Door does not support origins with private CA certificates in any scenario
B) The custom domain was not validated via CNAME, preventing TLS negotiation with the origin
C) Front Door cannot validate the origin certificate because the private CA is not recognized, and origin certificate verification was not disabled
D) HTTPS protocol is not available for origins on private networks without Private Link integration
Question 5 — Multiple Choice
When configuring an SSL Policy in Azure Application Gateway, what is the functional difference between using a Predefined policy and a Custom policy?
A) The Predefined policy automatically defines the listener's TLS certificate, while Custom allows using third-party certificates
B) The Predefined policy selects a fixed set of protocols and cipher suites maintained by Microsoft, while Custom allows explicitly choosing which protocols and cipher suites will be accepted
C) The Custom policy applies only to backend connections, while Predefined applies only to frontend
D) The Predefined policy uses TLS 1.3 exclusively, while Custom allows including older versions like TLS 1.0
Answer Key and Explanations
Answer Key — Question 1
Answer: B
In end-to-end TLS scenarios, the Application Gateway needs to validate the certificate presented by the backend server during the TLS handshake. When this certificate is self-signed or issued by a private CA, it does not belong to any publicly recognized trust chain. For the gateway to trust this certificate, it is necessary to upload the root certificate (or the self-signed certificate itself, which is its own trust anchor) as a Trusted Root Certificate within the backend HTTP settings.
Option A applies only when the backend certificate was issued by a recognized public CA; in this case, the "Use well-known CA certificate" flag dispenses with manual upload. Options C and D represent common misconceptions: the listener certificate protects the connection with the client, not the backend, and there is no SSL Policy that disables backend certificate chain verification as an officially supported mechanism.
Answer Key — Question 2
Answer: B
The control point for connection behavior between the Application Gateway and backend is the Backend HTTP Setting. The Protocol field determines whether the outbound connection will use HTTP or HTTPS, regardless of the protocol configured on the inbound listener. When this field is set to HTTP, the gateway decrypts the received traffic and forwards it in clear text, characterizing simple TLS termination, not end-to-end.
Option D is a frequent distractor: the port defined in the backend pool is used for routing, but the encryption protocol is determined exclusively by the Backend HTTP Setting. Option C is implausible because the SSL Policy controls protocol versions and cipher suites accepted on the frontend, not blocking outbound connections.
Answer Key — Question 3
Answer: True
Application Gateway v2 has been updated to automatically trust backend certificates issued by CAs present in the Mozilla Trusted CA Store, which includes the major public authorities in the market. In this case, the behavior is analogous to any modern TLS client: the trust chain is resolved automatically without manual intervention.
This behavior is significant because it represents an important difference from Application Gateway v1, which required certificate upload in all end-to-end TLS scenarios, including public CAs. Confusing the behavior between the two versions is a recurring error and can lead to unnecessarily complex configurations in environments that already use v2 with recognized CA certificates.
Answer Key — Question 4
Answer: C
Azure Front Door performs validation of the TLS certificate presented by the origin server during the handshake. When this certificate is issued by a corporate private CA, Front Door cannot build a trust chain to a recognized anchor, resulting in connection failure manifested as 502 Bad Gateway error.
The solution in this scenario involves disabling origin certificate verification in the Front Door origin configuration (an available option, but one that should be used with awareness of the risks) or replacing the origin certificate with one issued by a public CA.
Option A is incorrect because Front Door supports origins with private CA as long as verification is properly configured. Option B is a distractor that confuses client-side custom domain validation with origin certificate validation. Option D is incorrect because HTTPS for private origins is supported with or without Private Link, as long as the certificate is valid or verification is properly configured.
Answer Key — Question 5
Answer: B
The fundamental distinction between Predefined and Custom policies lies in the level of control over accepted TLS protocols and cipher suites. With a Predefined policy, the administrator chooses a profile maintained by Microsoft (such as AppGwSslPolicy20220101S), which includes a fixed and updated set of protocols and algorithms considered secure for that level. With a Custom policy, the administrator explicitly specifies which protocol versions (e.g., TLS 1.2, TLS 1.3) and which cipher suites will be enabled.
Option D represents a common misconception: no Predefined policy is exclusively TLS 1.3; all current predefined policies support at least TLS 1.2. Options A and C describe behaviors that simply do not exist; the SSL Policy has no relationship with certificate identity or connection direction (frontend versus backend).