Troubleshooting Lab: Map an existing custom DNS name to an App Service
Diagnostic Scenarios
Scenario 1 — Root Cause
The operations team reported that the domain api.contoso.com stops responding correctly every time the App Service is restarted or undergoes a slot swap. The environment uses the Standard S2 plan in a single region. The App Service was created six months ago and never had a dedicated IP configured. The administrator checks the DNS record at the external provider and finds the following:
api.contoso.com. 3600 IN A 40.112.72.205
The administrator also confirms that the custom domain is correctly added in the App Service configuration and that the TLS certificate is active. In the last 30 days, there have been three occurrences of the problem, always after platform maintenance operations.
What is the root cause of the observed problem?
A) The 3600-second TTL causes cached DNS to point to the old IP after restart, causing a downtime window
B) The A record points to the shared inbound IP address of the App Service, which is not stable and can change after restarts or platform operations
C) The slot swap invalidates the TLS certificate linked to the custom domain, interrupting resolution
D) The Standard S2 plan does not guarantee static inbound IP and requires upgrade to Premium for use with A records
Scenario 2 — Action Decision
The team identified that the domain portal.fabrikam.com is not responding. Upon investigation, the administrator discovers that the App Service was deleted and recreated with a new name (fabrikam-portal-v2) during an infrastructure migration performed the previous week. The external DNS record still points to the old name:
portal.fabrikam.com. 300 IN CNAME fabrikam-portal.azurewebsites.net
The new App Service is healthy, accessible via fabrikam-portal-v2.azurewebsites.net, and the custom domain portal.fabrikam.com has not yet been added to the new resource. The business team requires the domain to work again within 20 minutes maximum. Changing DNS records at the external provider has an estimated propagation of 5 to 10 minutes in the current environment.
What is the correct action to take at this moment?
A) Update the external CNAME record to fabrikam-portal-v2.azurewebsites.net before adding the custom domain to the new App Service
B) Add the custom domain portal.fabrikam.com to the new App Service first and, only after validation, update the external CNAME record
C) Recreate the App Service with the original name fabrikam-portal so the existing CNAME record works again without any DNS changes
D) Add an A record pointing to the new App Service IP while the old CNAME still exists, creating temporary redundancy
Scenario 3 — Root Cause
An administrator tried to map shop.alpineski.com to an existing App Service. The domain was already being used in another legacy system that was deactivated two months ago. The external DNS provider has the following active records:
shop.alpineski.com. 3600 IN CNAME alpineski-shop.azurewebsites.net
shop.alpineski.com. 3600 IN TXT ms-domain-verification=8f3a92b1c4d6e...
When trying to add the domain in the Azure portal, the operation fails with the following message:
The hostname 'shop.alpineski.com' is already assigned to another Azure resource.
Custom domain validation failed.
The administrator confirms that the App Service alpineski-shop exists, is active, and belongs to the same subscription. The managed certificate is configured and the plan tier is Premium P1v3.
What is the root cause of the failure?
A) The TXT verification record is associated with a previous App Service and Azure is rejecting the reuse of the same value
B) The domain shop.alpineski.com is already linked as a custom domain to another App Service within the Azure platform, even though the legacy system was deactivated
C) The Premium P1v3 plan has validation conflict with domains that have history in other service plans
D) The coexistence of a CNAME record and a TXT record on the same subdomain causes ambiguity in Azure validation
Scenario 4 — Diagnostic Sequence
A user reports that crm.woodgrove.com returns 404 Not Found error when accessed through the browser. The administrator knows the domain was recently configured. The following investigation steps are available, out of order:
[P1] Verify if the custom domain is added in the App Service configuration
[P2] Test DNS resolution with: nslookup crm.woodgrove.com
[P3] Access the App Service directly via azurewebsites.net URL to confirm it's healthy
[P4] Verify if the TXT record for ownership verification exists in external DNS
[P5] Confirm if the App Service is on the correct plan that supports custom domains
What is the correct diagnostic sequence?
A) P3, P2, P4, P1, P5
B) P5, P3, P2, P4, P1
C) P2, P3, P5, P4, P1
D) P3, P5, P2, P4, P1
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The central symptom is recurrent failure after restarts and maintenance operations, not after DNS changes or cache expiration. This is the decisive clue: the problem repeats predictably after each platform event.
The root cause is the use of an A record pointing to the shared inbound IP address of the App Service. This IP is not guaranteed to be stable in plans without dedicated IP. Operations like restarts, slot swaps, or infrastructure rebalancing can change the IP assigned to the App Service, invalidating the externally configured A record.
Alternative A is the most attractive distractor: the high TTL seems suspicious, but it only controls how long the cached value is maintained. If the IP didn't change, the TTL would be irrelevant to the problem. The high TTL would aggravate the failure duration, but wouldn't be its cause.
Alternative C is technically false: slot swaps do not invalidate properly linked TLS certificates.
Alternative D distorts reality: dedicated IP support is not as directly tied to plan tier as described, and this is not the cause of the observed behavior.
The most dangerous distractor is A: an administrator who acted by reducing the TTL would think they fixed the problem, but the failure would continue occurring after each restart.
Answer Key — Scenario 2
Answer: B
The critical constraint here is the 20-minute window. The correct sequence is first add the custom domain to the new App Service and then update the DNS, not the other way around.
If the CNAME is updated before the domain is added to the new App Service, there will be an interval where DNS already points to fabrikam-portal-v2.azurewebsites.net, but the App Service doesn't yet recognize the host portal.fabrikam.com. Requests arriving in this interval will receive 404 errors or undefined behavior, prolonging the downtime.
By adding the domain to the App Service first, Azure validates and registers the binding. Updating the CNAME afterward ensures that when traffic starts arriving through the new name, the destination is already prepared to accept it.
Alternative C ignores the time constraint and would create unnecessary work recreating infrastructure without guaranteeing the original name would be available.
Alternative D would create an inconsistent state: an A record and a CNAME on the same domain name cause unpredictable behavior depending on the DNS resolver, besides not solving the structural problem.
Answer Key — Scenario 3
Answer: B
The error message is the most objective clue: The hostname is already assigned to another Azure resource. This indicates that the domain shop.alpineski.com is still registered as a custom domain in another App Service within the Azure platform, even though the legacy system was "deactivated". Deactivating a system doesn't necessarily mean that the custom domain binding was removed from the corresponding App Service.
The information about the legacy system deactivated two months ago is the irrelevant information purposely inserted: it leads the reader to assume the domain was released, when in fact the binding in the old App Service may still exist even with the service stopped or unused.
The correct solution would be to locate the previous App Service (or its remaining record) and remove the custom domain from there before adding it to the new resource.
Alternative A attracts those who focus on the TXT record, but the verification value is generated per App Service and can be reused; it's not what causes the conflict described in the error message.
Alternative D is technically incorrect: the coexistence of CNAME and TXT in a subdomain is valid and is exactly what the mapping process requires.
Answer Key — Scenario 4
Answer: A
The correct sequence is: P3, P2, P4, P1, P5.
The correct diagnostic reasoning starts with the simplest and progressively eliminates variables:
| Step | Action | Justification |
|---|---|---|
| P3 | Access via .azurewebsites.net | Confirms the App Service is healthy before investigating DNS |
| P2 | Test DNS resolution | Verifies if the name resolves and to which destination |
| P4 | Verify TXT record | Confirms if ownership was properly declared in external DNS |
| P1 | Verify domain in App Service | Confirms if the binding was created in the platform |
| P5 | Confirm App Service plan | Validates SKU restriction, which is configuration verification, not state |
Starting with P5 (service plan) would be premature: it's a static prerequisite verification that rarely changes after initial configuration. Starting with P4 (TXT record) before confirming the App Service responds would be investigating DNS without knowing if the destination exists.
Alternative C places P2 as the first step, which makes sense superficially, but ignores that validating the App Service state first isolates the problem: if the service doesn't respond even by the default name, DNS is irrelevant.
Troubleshooting Tree: Map an existing custom DNS name to an App Service
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom (tree root) |
| Blue | Diagnostic question (binary or state decision) |
| Red | Identified cause (requires additional investigation) |
| Green | Recommended action or direct resolution |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, start at the root node and answer each question based on what you directly observe in the environment, without assuming any response. Follow the corresponding path until you reach a red node (cause) or green node (action). Orange nodes indicate that additional verification is needed before proceeding. The goal is to reach the terminal node through the shortest path of confirmed evidence, not the shortest path of assumptions.