Debugging scenarioMedium~10 minIdentity, Config & Edge Incidents / 5 of 7

Interview question

After an App Service slot swap, login fails because the identity provider redirects to the wrong callback URL. How would you debug it?

Debug broken authentication callbacks after an App Service swap

Diagnose authentication redirect or callback failures after a slot swap or domain change.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would capture the actual redirect URL, the configured callback URLs in the identity provider, and the app settings that control public origin or auth authority. Then I would check whether those settings are sticky to the slot and whether the production slot received a staging callback or base URL during swap. I would also inspect forwarded headers if a proxy or gateway is in front, because the app may generate an HTTP or internal host callback. The immediate fix is to restore the correct callback configuration and verify login end to end.

Full answer below

Practice focus

Auth callback URLs, slot settings, public origins, reverse proxy headers, identity provider configuration, and release safety.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Authentication callbacks depend on the real public scheme, host, path, proxy headers, cookie policy, identity-provider registration, and slot-owned configuration. A swap can expose a mismatch even when the application code is unchanged.
I would capture the actual redirect URL, the configured callback URLs in the identity provider, and the app settings that control public origin or auth authority. Then I would check whether those settings are sticky to the slot and whether the production slot received a staging callback or base URL during swap. I would also inspect forwarded headers if a proxy or gateway is in front, because the app may generate an HTTP or internal host callback. The immediate fix is to restore the correct callback configuration and verify login end to end.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would trace the login flow from browser to identity provider and back to the API or frontend. The important values are public scheme, host, path base, redirect URI, cookie domain, SameSite behavior, and environment-specific auth settings. If the login works on the Azure default hostname but not the custom domain, I would focus on public origin and proxy configuration. If only staging or production fails after swap, I would focus on slot settings and identity provider app registrations.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make auth callbacks part of the release checklist. Staging and production would have explicit redirect URLs, correct slot stickiness, and smoke tests that perform a real login against the target public domain. I would avoid changing identity provider settings during an incident without recording exactly what changed. After recovery, I would move public origin and callback configuration into reviewed infrastructure or deployment configuration so the next swap cannot silently trade auth settings.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Testing only the API health endpoint and not login.
Forgetting callback URLs during custom domain changes.
Letting staging auth settings swap into production.
Ignoring forwarded headers behind a proxy.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain redirect URI mismatch.
Does not inspect the actual browser redirect.
Has no idea which auth settings are slot-specific.
Fixes the identity provider manually with no release record.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Which auth settings belong to the slot?
How can forwarded headers break callback generation?
How would you smoke test login during release?

Continue the section

Next in Identity, Config & Edge Incidents: TLS or Domain Incident

Step 6 of 7

Debug a TLS certificate or domain binding incident in App Service

Opening drill

Debugging scenarioMedium~10 minIdentity, Config & Edge Incidents / 5 of 7

Interview question

After an App Service slot swap, login fails because the identity provider redirects to the wrong callback URL. How would you debug it?

Debug broken authentication callbacks after an App Service swap

Diagnose authentication redirect or callback failures after a slot swap or domain change.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Auth callback URLs, slot settings, public origins, reverse proxy headers, identity provider configuration, and release safety.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Authentication callbacks depend on the real public scheme, host, path, proxy headers, cookie policy, identity-provider registration, and slot-owned configuration. A swap can expose a mismatch even when the application code is unchanged.
I would capture the actual redirect URL, the configured callback URLs in the identity provider, and the app settings that control public origin or auth authority. Then I would check whether those settings are sticky to the slot and whether the production slot received a staging callback or base URL during swap. I would also inspect forwarded headers if a proxy or gateway is in front, because the app may generate an HTTP or internal host callback. The immediate fix is to restore the correct callback configuration and verify login end to end.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would trace the login flow from browser to identity provider and back to the API or frontend. The important values are public scheme, host, path base, redirect URI, cookie domain, SameSite behavior, and environment-specific auth settings. If the login works on the Azure default hostname but not the custom domain, I would focus on public origin and proxy configuration. If only staging or production fails after swap, I would focus on slot settings and identity provider app registrations.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make auth callbacks part of the release checklist. Staging and production would have explicit redirect URLs, correct slot stickiness, and smoke tests that perform a real login against the target public domain. I would avoid changing identity provider settings during an incident without recording exactly what changed. After recovery, I would move public origin and callback configuration into reviewed infrastructure or deployment configuration so the next swap cannot silently trade auth settings.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Testing only the API health endpoint and not login.
Forgetting callback URLs during custom domain changes.
Letting staging auth settings swap into production.
Ignoring forwarded headers behind a proxy.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain redirect URI mismatch.
Does not inspect the actual browser redirect.
Has no idea which auth settings are slot-specific.
Fixes the identity provider manually with no release record.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Which auth settings belong to the slot?
How can forwarded headers break callback generation?
How would you smoke test login during release?

Continue the section

Next in Identity, Config & Edge Incidents: TLS or Domain Incident

Step 6 of 7

Debug a TLS certificate or domain binding incident in App Service

After an App Service slot swap, login fails because the identity provider redirects to the wrong callback URL. How would you debug it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

After an App Service slot swap, login fails because the identity provider redirects to the wrong callback URL. How would you debug it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section