Technical Lab: Configure certificates and Transport Layer Security (TLS) for an App Service
Questions
Question 1 — Multiple Choice
You need to ensure that an App Service accepts only TLS 1.2 or higher connections. When reviewing the current configuration, you notice that the Minimum TLS Version field is set to 1.0. What is the correct path in the Azure portal to change this configuration?
A) App Service > Networking > TLS/SSL settings > Minimum TLS Version
B) App Service > Configuration > General settings > Minimum TLS Version
C) App Service > Custom domains > TLS/SSL bindings > Protocol version
D) App Service > Identity > TLS enforcement > Minimum TLS Version
Question 2 — Technical Scenario
A developer reports that when accessing https://app.contoso.com, the browser displays an invalid certificate warning. You check the App Service and confirm that a certificate has been uploaded and there is a binding configured for the custom domain. The certificate's expiration date is in the future and the domain is correctly mapped in DNS.
When inspecting the binding, you find the following configuration:
Custom domain: app.contoso.com
Certificate: contoso-cert (thumbprint: A1B2C3...)
TLS/SSL type: IP Based SSL
The App Service is on a Shared plan. What is the most likely cause of the problem?
A) The certificate was not exported with the private key included in the .pfx file
B) The Shared plan does not support IP Based SSL; the binding should be SNI SSL
C) The IP Based SSL type requires a dedicated IP address, unavailable on the Shared plan
D) The custom domain needs to be re-verified after configuring the binding
Question 3 — True or False
An App Service free managed certificate (App Service Managed Certificate) can be issued for a root domain (apex domain), such as contoso.com, as long as the domain is mapped via an A record in DNS.
Question 4 — Technical Scenario
Your team needs to deploy the same TLS certificate across three different App Services, all within the same subscription. The certificate was purchased from an external certificate authority and is available as a password-protected .pfx file. You want to centralize management and avoid manually uploading the file to each App Service.
What is the correct approach?
A) Upload the certificate to Azure Key Vault and reference the secret in each App Service via certificate configuration
B) Convert the .pfx to .cer and import it into the root certificate repository of each App Service
C) Use the App Service Certificate resource to issue a new certificate automatically linked to all three apps
D) Import the .pfx directly into one App Service and export the thumbprint to the others via ARM template
Question 5 — Multiple Choice
You configure an App Service TLS binding using SNI SSL. Shortly after, a client reports that connections made by a legacy device with Windows XP and Internet Explorer 6 fail with handshake error. What is the correct technical reason for this failure?
A) SNI SSL requires TLS 1.2, which is not supported by Internet Explorer 6
B) SNI SSL depends on a TLS protocol extension that legacy clients without SNI support don't send, preventing the server from identifying the correct certificate
C) SNI SSL binding doesn't work with certificates from external certificate authorities, only with managed certificates
D) Internet Explorer 6 doesn't support certificates with 2048-bit RSA keys, required by App Service
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The minimum TLS version configuration is located in Configuration > General settings, within the App Service platform configuration section. This panel controls general runtime behaviors, including the minimum accepted TLS version.
The other alternatives represent common misconceptions: "Networking" deals with virtual network integration and access restrictions; "Custom domains" manages domain mapping and bindings, but not protocol version; "Identity" is related to managed identities, with no relation to TLS.
Choosing alternative A or C would lead the administrator to look for a configuration in a non-existent location, with no effect on the minimum accepted protocol version.
Answer Key — Question 2
Answer: C
IP Based SSL binding allocates a dedicated IP address for the App Service, and this feature is not available on the Shared plan. Shared plans are intended for development and don't offer dedicated infrastructure. To use IP Based SSL, the App Service needs to be on a Basic plan or higher.
Alternative B is technically related but imprecise: the problem isn't that the binding "should be SNI SSL" as a configuration fix, but rather that the current plan simply doesn't support the chosen binding type, which prevents the binding from working correctly.
Alternative A would only be relevant at certificate upload time, not after the binding is already configured. Alternative D is a plausible distractor, but domain re-verification has no relation to the invalid certificate warning in the browser.
Answer Key — Question 3
Answer: False
The App Service Managed Certificate does not support root domains (apex domains). It is issued only for subdomains, such as www.contoso.com, and requires the domain to be mapped via a CNAME record pointing to the App Service's default hostname. A records are not accepted for this certificate type issuance.
This limitation is relevant because apex domains often use A records (or ALIAS/ANAME with some DNS providers), and administrators attempting to issue a managed certificate for contoso.com will receive an error. To cover apex domains with TLS, it's necessary to upload an external certificate or use an App Service Certificate.
Answer Key — Question 4
Answer: A
The correct approach is to store the certificate in Azure Key Vault and reference it in each App Service. App Service has native integration with Key Vault: when importing a certificate from a Key Vault secret, the service automatically obtains the certificate and even performs renewal when the secret is updated. This centralizes management and eliminates repetitive manual uploads.
Alternative C is a plausible distractor, but App Service Certificate is a product for certificate issuance and renewal via Microsoft's partner (GoDaddy), not for importing already purchased external certificates.
Alternative D represents an anti-pattern: the thumbprint identifies the locally uploaded certificate but is not a distribution mechanism between distinct App Services. Each App Service requires its own binding with the certificate present in its context.
Answer Key — Question 5
Answer: B
SNI (Server Name Indication) is a TLS protocol extension that allows the client to inform, during the handshake, which hostname it's trying to access. This enables a single IP address to serve multiple certificates. Clients that don't implement SNI, such as browsers on Windows XP, don't send this information, and the server cannot determine which certificate to present, resulting in handshake failure.
Alternative A is incorrect: SNI doesn't impose a minimum TLS version by itself. Protocol version restriction is configured separately.
Alternative D is a plausible distractor for those who confuse client limitations with server restrictions, but the real problem is the absence of SNI support, not RSA key size.