Debugging scenarioMedium~10 minStartup & Release Failures / 1 of 7

Interview question

A .NET API deployment completed, but the App Service app returns errors and never becomes healthy. How would you debug it?

Debug an App Service API that will not start after deployment

Diagnose a .NET API that fails to start on Azure App Service after a deployment.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would first confirm whether the deployment failed or the app deployed but cannot start. I would check deployment history, startup logs, App Service log stream, recent app setting changes, runtime version, and whether required secrets resolve. If users are affected, I would route traffic back to the last healthy slot or roll back before doing deeper analysis. Then I would reproduce against the staging slot or the same artifact so I can fix the cause, not just restart until it works.

Full answer below

Practice focus

Startup diagnosis, deployment logs, runtime mismatch, configuration checks, secret resolution, and impact mitigation.

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
Startup failures are common because deploy success only proves that files reached the host. This scenario checks whether you separate deployment transport, application startup, configuration, secrets, runtime, and dependency access.
I would first confirm whether the deployment failed or the app deployed but cannot start. I would check deployment history, startup logs, App Service log stream, recent app setting changes, runtime version, and whether required secrets resolve. If users are affected, I would route traffic back to the last healthy slot or roll back before doing deeper analysis. Then I would reproduce against the staging slot or the same artifact so I can fix the cause, not just restart until it works.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
After the first checks, I would classify the failure. A missing environment variable, bad Key Vault reference, wrong .NET runtime, startup exception, failed migration, blocked dependency, or incorrect startup command all look similar from the outside. I would compare the failing release to the last known good build: commit, package, configuration, slot settings, managed identity, database state, and platform logs. If the app starts locally but not in App Service, I would focus on hosting assumptions such as environment, file paths, ports, Linux versus Windows behavior, or missing production-only settings.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would run this as an incident with mitigation and diagnosis in parallel. I would preserve deployment logs and telemetry, name the exact user impact, and avoid random portal edits that create new drift. The recovery path depends on compatibility: swap back when the old version can safely run, disable a feature when the bad path is isolated, or roll forward when data or schema changes already moved forward. After the fix, I would add a startup validation, health check, or deployment gate that catches the same failure before production traffic sees it.

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

Assuming deployment success means the app started successfully.
Restarting repeatedly without reading startup or deployment logs.
Ignoring app settings, Key Vault references, and runtime version.
Rolling back without checking database or message compatibility.

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

Details

Cannot name where App Service startup and deployment logs live.
Treats every failure as application code before checking configuration.
Has no mitigation path while users are affected.
Cannot compare the failed release with the previous healthy one.

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 in App Service?
How would a bad Key Vault reference show up during startup?
When is swap-back unsafe after a failed release?

Continue the section

Next in Startup & Release Failures: 500 After Slot Swap

Step 2 of 7

Debug HTTP 500 errors after an App Service slot swap

Opening drill

Debugging scenarioMedium~10 minStartup & Release Failures / 1 of 7

Interview question

A .NET API deployment completed, but the App Service app returns errors and never becomes healthy. How would you debug it?

Debug an App Service API that will not start after deployment

Diagnose a .NET API that fails to start on Azure App Service after a deployment.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Startup diagnosis, deployment logs, runtime mismatch, configuration checks, secret resolution, and impact mitigation.

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
Startup failures are common because deploy success only proves that files reached the host. This scenario checks whether you separate deployment transport, application startup, configuration, secrets, runtime, and dependency access.
I would first confirm whether the deployment failed or the app deployed but cannot start. I would check deployment history, startup logs, App Service log stream, recent app setting changes, runtime version, and whether required secrets resolve. If users are affected, I would route traffic back to the last healthy slot or roll back before doing deeper analysis. Then I would reproduce against the staging slot or the same artifact so I can fix the cause, not just restart until it works.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
After the first checks, I would classify the failure. A missing environment variable, bad Key Vault reference, wrong .NET runtime, startup exception, failed migration, blocked dependency, or incorrect startup command all look similar from the outside. I would compare the failing release to the last known good build: commit, package, configuration, slot settings, managed identity, database state, and platform logs. If the app starts locally but not in App Service, I would focus on hosting assumptions such as environment, file paths, ports, Linux versus Windows behavior, or missing production-only settings.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would run this as an incident with mitigation and diagnosis in parallel. I would preserve deployment logs and telemetry, name the exact user impact, and avoid random portal edits that create new drift. The recovery path depends on compatibility: swap back when the old version can safely run, disable a feature when the bad path is isolated, or roll forward when data or schema changes already moved forward. After the fix, I would add a startup validation, health check, or deployment gate that catches the same failure before production traffic sees it.

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

Assuming deployment success means the app started successfully.
Restarting repeatedly without reading startup or deployment logs.
Ignoring app settings, Key Vault references, and runtime version.
Rolling back without checking database or message compatibility.

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

Details

Cannot name where App Service startup and deployment logs live.
Treats every failure as application code before checking configuration.
Has no mitigation path while users are affected.
Cannot compare the failed release with the previous healthy one.

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 in App Service?
How would a bad Key Vault reference show up during startup?
When is swap-back unsafe after a failed release?

Continue the section

Next in Startup & Release Failures: 500 After Slot Swap

Step 2 of 7

Debug HTTP 500 errors after an App Service slot swap

A .NET API deployment completed, but the App Service app returns errors and never becomes healthy. How would you debug it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

A .NET API deployment completed, but the App Service app returns errors and never becomes healthy. How would you debug it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section