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

Interview question

After a release, an App Service-hosted .NET API shows high CPU or memory and slow responses. How would you debug it?

Debug CPU or memory spikes after an App Service release

Investigate resource spikes on App Service after a new .NET API release.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would first identify whether the spike is CPU, memory, requests, dependency latency, or a combination. I would compare the time of the spike with the deployment, traffic volume, error rate, and App Service instance metrics. If users are affected, I would reduce impact with rollback, feature disablement, scale-out, or throttling depending on the symptom. Then I would use Application Insights, logs, and App Service diagnostics to find the route, dependency, or code path that changed.

Full answer below

Practice focus

Resource metrics, instance-level telemetry, profiling, dependency latency, memory leaks, GC pressure, and 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
A post-release resource spike can come from changed traffic, hot code paths, retry amplification, dependency slowdown, retained memory, or uneven instance health. The deployment timeline and per-instance evidence help separate correlation from cause before scaling hides the symptom.
I would first identify whether the spike is CPU, memory, requests, dependency latency, or a combination. I would compare the time of the spike with the deployment, traffic volume, error rate, and App Service instance metrics. If users are affected, I would reduce impact with rollback, feature disablement, scale-out, or throttling depending on the symptom. Then I would use Application Insights, logs, and App Service diagnostics to find the route, dependency, or code path that changed.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For CPU, I would look for hot endpoints, synchronous blocking, excessive serialization, expensive loops, or retry storms. For memory, I would look for growing working set, Large Object Heap pressure, retained objects, in-memory caches, large response buffering, or leaked subscriptions. If the spike only appears under scale-out, I would compare per-instance telemetry and check whether one instance is unhealthy or all instances are saturated. I would avoid treating scale as the fix until I know whether the app is doing more work than intended.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would pair immediate mitigation with root-cause capture. A profile, dump, logs, and deployment metadata are most valuable while the issue is happening, but collection must avoid making the outage worse. The long-term fix might be a query change, bounded concurrency, streaming, cache limit, retry policy, or background worker design. I would also verify whether autoscale rules, health checks, and instance recycling made the symptom better or worse during the incident. I would add an alert or dashboard for the leading signal so the next occurrence is caught before users report 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

Scaling up immediately without checking the bottleneck.
Looking only at average metrics instead of per-instance behavior.
Ignoring dependency latency and retry storms.
Failing to capture diagnostic data during the incident.

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

Details

Cannot name different evidence for CPU versus memory.
Has no mitigation option beyond restart.
Ignores deployment timing and route-level telemetry.
Treats App Service plan scaling as a universal fix.

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 would you check first for high CPU?
How would you diagnose memory growth safely?
When is scale-out a mitigation rather than a fix?

Continue the section

Next in Startup & Release Failures: No Useful Logs

Step 6 of 7

Debug an App Service incident when logs show nothing useful

Opening drill

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

Interview question

After a release, an App Service-hosted .NET API shows high CPU or memory and slow responses. How would you debug it?

Debug CPU or memory spikes after an App Service release

Investigate resource spikes on App Service after a new .NET API release.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Resource metrics, instance-level telemetry, profiling, dependency latency, memory leaks, GC pressure, and 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
A post-release resource spike can come from changed traffic, hot code paths, retry amplification, dependency slowdown, retained memory, or uneven instance health. The deployment timeline and per-instance evidence help separate correlation from cause before scaling hides the symptom.
I would first identify whether the spike is CPU, memory, requests, dependency latency, or a combination. I would compare the time of the spike with the deployment, traffic volume, error rate, and App Service instance metrics. If users are affected, I would reduce impact with rollback, feature disablement, scale-out, or throttling depending on the symptom. Then I would use Application Insights, logs, and App Service diagnostics to find the route, dependency, or code path that changed.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For CPU, I would look for hot endpoints, synchronous blocking, excessive serialization, expensive loops, or retry storms. For memory, I would look for growing working set, Large Object Heap pressure, retained objects, in-memory caches, large response buffering, or leaked subscriptions. If the spike only appears under scale-out, I would compare per-instance telemetry and check whether one instance is unhealthy or all instances are saturated. I would avoid treating scale as the fix until I know whether the app is doing more work than intended.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would pair immediate mitigation with root-cause capture. A profile, dump, logs, and deployment metadata are most valuable while the issue is happening, but collection must avoid making the outage worse. The long-term fix might be a query change, bounded concurrency, streaming, cache limit, retry policy, or background worker design. I would also verify whether autoscale rules, health checks, and instance recycling made the symptom better or worse during the incident. I would add an alert or dashboard for the leading signal so the next occurrence is caught before users report 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

Scaling up immediately without checking the bottleneck.
Looking only at average metrics instead of per-instance behavior.
Ignoring dependency latency and retry storms.
Failing to capture diagnostic data during the incident.

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

Details

Cannot name different evidence for CPU versus memory.
Has no mitigation option beyond restart.
Ignores deployment timing and route-level telemetry.
Treats App Service plan scaling as a universal fix.

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 would you check first for high CPU?
How would you diagnose memory growth safely?
When is scale-out a mitigation rather than a fix?

Continue the section

Next in Startup & Release Failures: No Useful Logs

Step 6 of 7

Debug an App Service incident when logs show nothing useful

After a release, an App Service-hosted .NET API shows high CPU or memory and slow responses. How would you debug it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

After a release, an App Service-hosted .NET API shows high CPU or memory and slow responses. How would you debug it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section