Debugging scenarioEasy~8 min

Interview question

After changing the frontend or API custom domain, browser calls fail with CORS errors. How would you debug it?

Debug CORS failures after a custom domain change

Diagnose browser CORS errors after moving an Azure-hosted API or frontend to a new custom domain.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would inspect the browser network tab and identify the exact origin, method, headers, and preflight response. Then I would compare that origin to the API CORS configuration, including scheme, host, and port. If the API moved behind a custom domain or proxy, I would verify the public URL that the browser is actually calling. I would avoid using wildcard CORS with credentials as a production fix.

Full answer below

Practice focus

CORS origins, browser enforcement, custom domains, preflight requests, auth cookies, and safe production configuration.

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
Browsers enforce CORS against the exact public origin and preflight response. A domain change can expose differences in scheme, host, port, allowed headers, credentials, cookies, redirects, or proxy behavior that server-side tests do not exercise.
I would inspect the browser network tab and identify the exact origin, method, headers, and preflight response. Then I would compare that origin to the API CORS configuration, including scheme, host, and port. If the API moved behind a custom domain or proxy, I would verify the public URL that the browser is actually calling. I would avoid using wildcard CORS with credentials as a production fix.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would also check whether the failure is really CORS or an authentication/configuration error that the browser reports as CORS because the response lacks headers. Preflight can fail because allowed methods or headers are incomplete, while the actual request can fail because cookies, SameSite, HTTPS, or auth redirects changed. I would verify frontend environment variables, API base URLs, App Service allowed origins, and any gateway that may add or strip headers.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would keep CORS narrow and environment-owned. Each public frontend origin would be explicitly configured, credentials would only be enabled when required, and staging origins would not leak into production. I would test both preflight and the authenticated request through the real custom domain, including cookies, SameSite, HTTPS redirects, forwarded headers, and any gateway behavior. If the response is an auth redirect or platform error, I would fix that underlying failure rather than broadening CORS to hide it. The allowed-origin list would live in reviewed configuration with a post-domain-change smoke check and a known rollback path, not in an emergency wildcard.

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

Adding * in production to make the browser error disappear.
Ignoring the scheme and port when comparing origins.
Confusing CORS with server-to-server authorization.
Not checking preflight method and header requirements.

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

Details

Cannot define an origin precisely.
Suggests wildcard CORS with credentials.
Does not inspect the browser preflight request.
Ignores auth cookies and redirects after domain changes.

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.

What makes two URLs different origins?
How do credentials change CORS configuration?
How would you test CORS in staging?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Abstraction vs encapsulationConcept question / Easy / ~5 minContinue Access modifiersConcept question / Easy / ~5 minContinue ActionResult vs Typed ResultsComparison question / Medium / ~7 minContinue

Debugging scenarioEasy~8 min

Interview question

After changing the frontend or API custom domain, browser calls fail with CORS errors. How would you debug it?

Debug CORS failures after a custom domain change

Diagnose browser CORS errors after moving an Azure-hosted API or frontend to a new custom domain.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

CORS origins, browser enforcement, custom domains, preflight requests, auth cookies, and safe production configuration.

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
Browsers enforce CORS against the exact public origin and preflight response. A domain change can expose differences in scheme, host, port, allowed headers, credentials, cookies, redirects, or proxy behavior that server-side tests do not exercise.
I would inspect the browser network tab and identify the exact origin, method, headers, and preflight response. Then I would compare that origin to the API CORS configuration, including scheme, host, and port. If the API moved behind a custom domain or proxy, I would verify the public URL that the browser is actually calling. I would avoid using wildcard CORS with credentials as a production fix.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would also check whether the failure is really CORS or an authentication/configuration error that the browser reports as CORS because the response lacks headers. Preflight can fail because allowed methods or headers are incomplete, while the actual request can fail because cookies, SameSite, HTTPS, or auth redirects changed. I would verify frontend environment variables, API base URLs, App Service allowed origins, and any gateway that may add or strip headers.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would keep CORS narrow and environment-owned. Each public frontend origin would be explicitly configured, credentials would only be enabled when required, and staging origins would not leak into production. I would test both preflight and the authenticated request through the real custom domain, including cookies, SameSite, HTTPS redirects, forwarded headers, and any gateway behavior. If the response is an auth redirect or platform error, I would fix that underlying failure rather than broadening CORS to hide it. The allowed-origin list would live in reviewed configuration with a post-domain-change smoke check and a known rollback path, not in an emergency wildcard.

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

Adding * in production to make the browser error disappear.
Ignoring the scheme and port when comparing origins.
Confusing CORS with server-to-server authorization.
Not checking preflight method and header requirements.

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

Details

Cannot define an origin precisely.
Suggests wildcard CORS with credentials.
Does not inspect the browser preflight request.
Ignores auth cookies and redirects after domain changes.

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.

What makes two URLs different origins?
How do credentials change CORS configuration?
How would you test CORS in staging?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

After changing the frontend or API custom domain, browser calls fail with CORS errors. How would you debug it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

After changing the frontend or API custom domain, browser calls fail with CORS errors. How would you debug it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice