Skip to main content

Technical Lab: Configure Transport Layer Security (TLS)

Questions​

Question 1 — Multiple Choice​

An architecture team needs to publish an internal REST API that requires TLS termination at the gateway, with the capability to inspect and modify HTTP headers before forwarding traffic to the backend. The backend operates in plain HTTP within the virtual network.

Which configuration combination in Azure Application Gateway meets this requirement?

A) HTTPS listener on port 443 with SSL certificate on the gateway, and HTTP backend configuration without authentication certificate.

B) HTTPS listener on port 443 with SSL certificate on the gateway, and HTTPS backend configuration with mandatory authentication certificate.

C) HTTP listener on port 80 with redirect to HTTPS, and HTTPS backend with end-to-end TLS.

D) HTTPS listener on port 443 without certificate on the gateway, delegating TLS negotiation directly to the backend via TCP tunnel.

Question 2 — Technical Scenario​

An engineer configured Azure Front Door to distribute traffic to two regional backends. After deployment, users report that HTTPS connections work, but the certificate presented to the client is self-signed and the browser displays a security warning.

The relevant origin group configuration is below:

{
  "httpsSettings": {
    "certificateNameCheck": "Disabled",
    "minimumTlsVersion": "TLS10"
  },
  "customDomain": {
    "tlsSettings": {
      "certificateType": "CustomerCertificate",
      "minimumTlsVersion": "TLS12"
    }
  }
}

What is the most likely cause of the warning displayed in the browser?

A) The origin minimumTlsVersion is set to TLS10, which forces Front Door to downgrade the protocol in the client connection.

B) The certificateType is set to CustomerCertificate, but no valid certificate issued by a public CA has been provisioned in the custom domain.

C) The disabled certificateNameCheck on the origin causes the backend certificate to be presented directly to the client without replacement.

D) The custom domain minimum TLS version is set to TLS12, which prevents clients with TLS 1.3 from connecting properly.

Question 3 — True or False​

Statement: In Azure Application Gateway, when configured with end-to-end TLS, the certificate installed in the backend pool must be issued by a publicly recognized certificate authority; self-signed certificates are not supported in this scenario.

True or False?

Question 4 — Technical Scenario​

An organization uses Azure API Management (APIM) in Premium tier with virtual network integration in internal mode. The security team requires that only clients presenting a valid client certificate can invoke exposed APIs. The policy below was applied at the inbound layer of a specific API:

<policies>
  <inbound>
    <choose>
      <when condition="@(context.Request.Certificate == null)">
        <return-response>
          <set-status code="401" reason="Unauthorized" />
        </return-response>
      </when>
    </choose>
  </inbound>
</policies>

After deployment, the test team finds that requests without client certificates are being accepted with status 200. What is the most likely cause?

A) The choose policy is not supported in the inbound layer of APIM; it must be applied in the backend layer.

B) Client certificate negotiation is not enabled on the APIM gateway, so context.Request.Certificate is always null and the condition is never satisfied as expected.

C) The Negotiate client certificate option is not enabled in APIM, causing context.Request.Certificate to never be null, even in requests without certificates.

D) Internal virtual network mode blocks client certificate inspection, requiring validation to be done by an Azure Application Gateway positioned in front of APIM.

Question 5 — Multiple Choice​

When configuring a custom SSL policy in Azure Application Gateway, an engineer needs to ensure that only TLS 1.2 and TLS 1.3 are accepted, disabling earlier versions. They also need to restrict cipher suites to remove algorithms with RSA keys smaller than 2048 bits.

Which statement correctly describes the expected behavior after this configuration?

A) The Application Gateway will accept TLS 1.0 as automatic fallback if the client doesn't support TLS 1.2, regardless of the defined policy.

B) The custom SSL policy applies only to the connection between client and gateway; the connection between gateway and backend is governed by the backend HTTP configuration, not the SSL policy.

C) The custom SSL policy controls both the inbound connection (client to gateway) and outbound connection (gateway to backend) with the same cipher suite restrictions.

D) Disabling TLS 1.0 and 1.1 in the Application Gateway SSL policy also automatically disables these protocols on backend instances associated with the same gateway.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: A

The scenario describes TLS termination (or SSL offloading), not end-to-end TLS. In this model, the Application Gateway terminates the TLS session with the client using its own certificate, processes the HTTP content in plain text, and forwards to the backend via plain HTTP. Option A describes exactly this: HTTPS listener with certificate on the gateway and backend configured in HTTP without certificate requirement.

Option B describes end-to-end TLS, where the backend also needs to present a certificate. Option C adds a redirect step and maintains TLS on the backend, not meeting the plain HTTP backend requirement. Option D is technically invalid: the Application Gateway doesn't operate as a transparent TCP proxy for TLS; it needs the certificate to negotiate the session with the client.

Answer Key — Question 2​

Answer: B

The browser warning indicates that the certificate presented to the client is not trusted. In Azure Front Door, when certificateType is CustomerCertificate, it's the operator's responsibility to provision a valid certificate issued by a public CA in the associated Key Vault. If the certificate wasn't properly provisioned or is self-signed, Front Door will present this invalid certificate to clients.

Option A is a common misconception: the origin minimumTlsVersion governs the connection between Front Door and backend, not between Front Door and client. Option C confuses the behavior of certificateNameCheck on the origin, which controls backend certificate validation by Front Door, not what's presented to the client. Option D reverses the logic: TLS 1.2 as minimum version is more restrictive, doesn't prevent TLS 1.3, and doesn't cause certificate warnings.

Answer Key — Question 3​

Answer: False

In Application Gateway with end-to-end TLS, self-signed certificates are supported on backends. What the gateway requires in this case is that the public key (or root certificate, depending on SKU) of the backend certificate be added to the backend HTTP configuration as authentication certificate (Standard/WAF SKU) or trusted root certificate (v2 SKU). This allows the gateway to validate the backend even with self-signed certificates, without requiring public CA issuance. Requiring public CA for backends would be impractical in internal environments where private certificates are the norm.

Answer Key — Question 4​

Answer: C

This is a subtle logic error. When the Negotiate client certificate option is not enabled in APIM, the gateway doesn't request the client certificate during the TLS handshake. As a consequence, context.Request.Certificate is never null in this state; it simply doesn't exist as a populated object, and the policy expression evaluates in a way that the == null condition doesn't trigger the 401 return as expected by the engineer.

Option B describes the opposite symptom: if Certificate were always null, the policy would block all requests, not approve them. Option A is incorrect because choose is fully supported in inbound. Option D describes a limitation that doesn't exist: internal virtual network mode doesn't prevent client certificate inspection.

Answer Key — Question 5​

Answer: B

The custom SSL policy of Application Gateway governs exclusively the connection between client and gateway, i.e., the ingress layer. The connection between gateway and backend is controlled by the backend HTTP settings (Backend HTTP Settings), where you define whether TLS is enabled, which minimum version to accept, and whether the backend certificate should be validated. These two layers are independent and configured separately.

Option A is false: the custom SSL policy is enforced without fallback; disabled versions are rejected. Option C is the most common misconception, representing confusion between the two TLS layers in Application Gateway. Option D extrapolates the gateway policy scope to backends, which doesn't occur; backends are independent resources with their own TLS configuration.