Debugging scenarioMedium~10 min

Interview question

A .NET API deployment to Azure App Service completed, but the app returns errors or will not start. How do you debug it?

How would you diagnose a failed Azure App Service deployment?

Covers deployment logs, startup failures, runtime stack, app settings, missing files, Key Vault references, and post-deployment diagnosis.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would first separate deployment failure from application startup failure. I would check deployment logs, whether the expected artifact reached the slot, App Service runtime version, startup logs, app settings, Key Vault references, and recent database migrations. If the app starts but fails requests, I would move to request logs, dependency failures, and Application Insights traces.

Full answer below

Practice focus

Deployment diagnosis, App Service logs, startup config, runtime mismatch, secret resolution, health checks, and rollback decisions.

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
A completed deployment can still fail at artifact extraction, process startup, configuration resolution, identity, dependency access, migration compatibility, or request handling. Diagnosis starts by locating that boundary before changing the system again.
I would first separate deployment failure from application startup failure. I would check deployment logs, whether the expected artifact reached the slot, App Service runtime version, startup logs, app settings, Key Vault references, and recent database migrations. If the app starts but fails requests, I would move to request logs, dependency failures, and Application Insights traces.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would compare the broken deployment with the last known good one: commit, package, runtime, settings, slot, identity, database state, and dependency endpoints. A failed deploy can be caused by the build artifact, missing files, wrong framework version, bad config, unresolved secret, startup exception, blocked dependency, or a migration mismatch. I would use the staging slot, log stream, deployment history, and telemetry to classify the failure before choosing rollback, re-deploy, config fix, or hotfix.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would run this like an incident, with impact reduction and evidence preservation happening together. If users are affected, I would decide whether to route back to a healthy slot, disable a feature, or stop the rollout. Then I would inspect platform logs, application logs, identity and Key Vault access, dependency access, health checks, and database changes in order. That sequence narrows the failure deliberately and avoids random portal changes that erase evidence or introduce a second problem.

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

Debugging code before checking whether the app started.
Ignoring slot settings and Key Vault reference resolution.
Making untracked portal changes during an incident.
No mitigation while users keep hitting errors.

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

Details

Cannot name where App Service deployment or startup logs are found.
No distinction between deployment failure and runtime failure.
Does not check recent configuration or identity changes.
Keeps retrying the same deployment without new evidence.

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 logs would you check first?
How would you tell startup failure from request failure?
What Key Vault problems can break startup?
When would you swap back instead of debugging live?

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

Opening drill

Debugging scenarioMedium~10 min

Interview question

A .NET API deployment to Azure App Service completed, but the app returns errors or will not start. How do you debug it?

How would you diagnose a failed Azure App Service deployment?

Covers deployment logs, startup failures, runtime stack, app settings, missing files, Key Vault references, and post-deployment diagnosis.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Deployment diagnosis, App Service logs, startup config, runtime mismatch, secret resolution, health checks, and rollback decisions.

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
A completed deployment can still fail at artifact extraction, process startup, configuration resolution, identity, dependency access, migration compatibility, or request handling. Diagnosis starts by locating that boundary before changing the system again.
I would first separate deployment failure from application startup failure. I would check deployment logs, whether the expected artifact reached the slot, App Service runtime version, startup logs, app settings, Key Vault references, and recent database migrations. If the app starts but fails requests, I would move to request logs, dependency failures, and Application Insights traces.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would compare the broken deployment with the last known good one: commit, package, runtime, settings, slot, identity, database state, and dependency endpoints. A failed deploy can be caused by the build artifact, missing files, wrong framework version, bad config, unresolved secret, startup exception, blocked dependency, or a migration mismatch. I would use the staging slot, log stream, deployment history, and telemetry to classify the failure before choosing rollback, re-deploy, config fix, or hotfix.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would run this like an incident, with impact reduction and evidence preservation happening together. If users are affected, I would decide whether to route back to a healthy slot, disable a feature, or stop the rollout. Then I would inspect platform logs, application logs, identity and Key Vault access, dependency access, health checks, and database changes in order. That sequence narrows the failure deliberately and avoids random portal changes that erase evidence or introduce a second problem.

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

Debugging code before checking whether the app started.
Ignoring slot settings and Key Vault reference resolution.
Making untracked portal changes during an incident.
No mitigation while users keep hitting errors.

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

Details

Cannot name where App Service deployment or startup logs are found.
No distinction between deployment failure and runtime failure.
Does not check recent configuration or identity changes.
Keeps retrying the same deployment without new evidence.

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 logs would you check first?
How would you tell startup failure from request failure?
What Key Vault problems can break startup?
When would you swap back instead of debugging live?

Continue practice

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

A .NET API deployment to Azure App Service completed, but the app returns errors or will not start. How do you debug it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

A .NET API deployment to Azure App Service completed, but the app returns errors or will not start. How do you debug it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice