Technical Lab: Map an existing custom DNS name to an App Service
Questions
Question 1 — Multiple Choice
You need to map the domain loja.contoso.com to an App Service in Azure. When trying to add the custom domain name in the portal, the validation button returns an error indicating that domain ownership has not been confirmed.
Which DNS record is mandatory for Azure to confirm domain ownership before allowing the mapping?
A) An A record pointing to the App Service IP address
B) A CNAME record pointing to the default .azurewebsites.net domain
C) A TXT record containing the verification ID generated by the App Service
D) An NS record delegating the zone to Azure DNS servers
Question 2 — Technical Scenario
A team configured the mapping of the domain app.fabrikam.com using a CNAME record pointing to fabrikam-prod.azurewebsites.net. The mapping works correctly. A few weeks later, the team decides to configure a second App Service in a different region for failover and wants the same domain app.fabrikam.com to point to this new resource temporarily.
When trying to add app.fabrikam.com as a custom domain in the second App Service, the portal returns a conflict error.
What is the cause of the error?
A) The CNAME record in external DNS still points to the first App Service, preventing validation on the second
B) A custom domain name can only be linked to a single App Service at a time within the same subscription
C) The second App Service is in a different region and doesn't support shared custom domains
D) The App Service plan doesn't have sufficient SKU to accept a second custom domain
Question 3 — True or False
A CNAME record can be used to map the root domain (also called apex domain), such as contoso.com without subdomain, directly to an App Service in Azure, as long as the external DNS provider supports CNAME flattening functionality.
True or False?
Question 4 — Technical Scenario
An administrator needs to map portal.contoso.com to an App Service. The App Service uses a shared inbound IP address (no dedicated IP is configured). The administrator created the following DNS record in the external provider:
portal.contoso.com. 300 IN A 20.10.45.200
After waiting for DNS propagation, when accessing portal.contoso.com, the browser returns a 404 error and the Azure portal indicates that the domain is still not mapped.
What is the error in this configuration?
A) The TTL of 300 seconds is too low and prevents the record from being propagated correctly
B) An A record requires the App Service to have a dedicated inbound IP address; without it, the correct IP is not stable
C) The A record was created, but the custom domain has not yet been added to the App Service configuration
D) The IP address 20.10.45.200 belongs to the Azure load balancer and cannot be used in external A records
Question 5 — Multiple Choice
When comparing the use of CNAME record versus A record to map a custom domain to an App Service, which statement correctly describes a relevant functional difference between the two methods?
A) The A record requires ownership verification via TXT, while CNAME completely bypasses this step
B) The CNAME record cannot be used for subdomains; it is exclusive to root domains
C) The A record uses the App Service inbound IP address and requires manual update if that IP changes, while CNAME automatically follows any changes in the target domain address
D) The CNAME record offers better DNS resolution performance in corporate networks by using direct recursive resolution
Answer Key and Explanations
Answer Key — Question 1
Answer: C
Azure requires the administrator to prove domain ownership before allowing the binding. This is done by creating a TXT record in the external DNS provider with a specific value generated by the App Service, called the Custom Domain Verification ID. Without this record, Azure rejects the mapping even if the resolution record (A or CNAME) already exists.
The distractors represent a common misconception: confusing the record responsible for resolution (where traffic goes) with the record responsible for ownership verification (who controls the domain). The A and CNAME records resolve the name, but don't prove ownership. The NS record delegates zone authority, which is irrelevant to this flow.
Answer Key — Question 2
Answer: B
Azure doesn't allow the same custom domain name to be linked to more than one App Service simultaneously within the platform, regardless of region or subscription. The portal rejects the attempt to add the domain to the second resource because it's already registered as a custom domain on the first one.
Alternative A describes a different scenario: the external CNAME points to a target, but ownership validation via TXT is not tied to the current traffic destination. Alternative C is false: different regions don't impose this restriction. Alternative D confuses SKU limitations (which affect the number of domains per App Service) with ownership conflict between distinct resources.
Answer Key — Question 3
False
From the perspective of the standard DNS protocol (RFC 1034), a CNAME record at the apex domain is technically invalid because the apex also needs to have SOA and NS records, and these cannot coexist with a CNAME at the same node. Therefore, using CNAME for the root domain is not natively supported.
What some providers offer is a proprietary functionality called CNAME flattening (or ALIAS/ANAME), which resolves the CNAME internally and publishes the result as an A record. This is not a real CNAME at the apex: it's a provider abstraction. Azure DNS offers alias records for this purpose. The statement is false because it describes a CNAME directly at the apex as supported, which violates DNS specification and is not what Azure recommends or implements.
Answer Key — Question 4
Answer: C
Creating the correct DNS record in the external provider is only half the process. The administrator also needs to explicitly add the custom domain to the App Service configuration in the portal or via CLI/API. These are two independent steps: external DNS controls name resolution, and the App Service needs to know which domains it's authorized to accept. Without the binding in the App Service, requests reach the IP, but the App Service doesn't accept them for that host, resulting in 404 or undefined behavior.
Alternative B is a technically true point in general terms (shared IP is not stable enough for long-duration A records), but it's not the cause of the error described in the question, as the problem is structural: the domain was simply never registered in the App Service. The TTL (alternative A) affects propagation speed, not mapping validity.
Answer Key — Question 5
Answer: C
The A record links a name to a specific IP address. If the App Service is migrated, recreated, or if the inbound IP changes for any reason, the A record needs to be manually updated. The CNAME record, by pointing to a name (like fabrikam.azurewebsites.net), automatically follows any changes in the underlying address, making it more resilient to infrastructure changes.
Alternative A is wrong: both methods require ownership verification via TXT. Alternative B reverses reality: CNAME is exclusive to subdomains; the apex doesn't support native CNAME. Alternative D is a distractor without technical foundation related to the actual functioning of DNS records or resolution behavior in corporate networks.