Debugging scenarioMedium~10 minAzure Production Incident Debugging Essentials / 10 of 15

Interview question

An App Service-hosted .NET API uses managed identity for Azure SQL, but login fails in production. How would you debug it?

Debug managed identity login failures to Azure SQL

Diagnose a .NET API that cannot connect to Azure SQL using managed identity.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would confirm that the App Service has the expected managed identity and that the connection string uses Microsoft Entra managed identity authentication, not SQL password authentication. Then I would verify that Azure SQL has a user mapped for that identity and that the user has the required permissions. I would also check SQL firewall, private endpoint, VNet integration, and whether the failing environment uses the same identity as the one that was granted access. The error message usually tells whether this is authentication, authorization, or network access.

Full answer below

Practice focus

Managed identity assignment, SQL user mapping, connection string authentication mode, firewall/private endpoint access, and runtime permissions.

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
Managed identity login to Azure SQL crosses token acquisition, network reachability, database user mapping, and authorization. Separating those layers prevents a permission problem from being treated as a connection problem or vice versa.
I would confirm that the App Service has the expected managed identity and that the connection string uses Microsoft Entra managed identity authentication, not SQL password authentication. Then I would verify that Azure SQL has a user mapped for that identity and that the user has the required permissions. I would also check SQL firewall, private endpoint, VNet integration, and whether the failing environment uses the same identity as the one that was granted access. The error message usually tells whether this is authentication, authorization, or network access.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would separate identity acquisition from database permission. The app may acquire a token successfully and still fail because the database user does not exist or lacks rights. It may also have correct database rights but fail before SQL because network rules block the connection. For EF Core, I would check whether the runtime path and migration path use different identities or permissions. Runtime access can be least privilege, while migrations may need a separate controlled identity. I would prove the fix with a small production-safe connectivity check rather than assuming the next user request will tell me.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would keep the fix least-privileged and auditable. I would not switch back to a stored SQL password unless it is a deliberate emergency mitigation with a rollback plan. I would review identity ownership, environment separation, SQL user mapping, schema permissions, connection pooling, and transient fault behavior. I would also monitor failed login count and token acquisition errors so the team can tell identity drift from database pressure. After recovery, I would add a deployment smoke check that proves the app identity can open the intended database without granting migration-level permissions to normal request traffic.

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

Creating a managed identity but never creating a database user for it.
Using the wrong identity in staging versus production.
Fixing runtime access by granting broad database owner permissions.
Ignoring firewall or private endpoint rules.

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

Details

Cannot distinguish token acquisition from SQL authorization.
Does not inspect the actual connection string authentication mode.
Uses one powerful identity for every app and environment.
Has no plan for migrations versus runtime permissions.

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.

How do you grant an App Service identity access to Azure SQL?
What would you check if token acquisition works but SQL login fails?
How would you handle EF migrations securely?

Continue the section

Next in Azure Production Incident Debugging Essentials: Slot Config Drift

Step 11 of 15

Debug configuration drift between App Service slots

Opening drill

Debugging scenarioMedium~10 minAzure Production Incident Debugging Essentials / 10 of 15

Interview question

An App Service-hosted .NET API uses managed identity for Azure SQL, but login fails in production. How would you debug it?

Debug managed identity login failures to Azure SQL

Diagnose a .NET API that cannot connect to Azure SQL using managed identity.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Managed identity assignment, SQL user mapping, connection string authentication mode, firewall/private endpoint access, and runtime permissions.

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
Managed identity login to Azure SQL crosses token acquisition, network reachability, database user mapping, and authorization. Separating those layers prevents a permission problem from being treated as a connection problem or vice versa.
I would confirm that the App Service has the expected managed identity and that the connection string uses Microsoft Entra managed identity authentication, not SQL password authentication. Then I would verify that Azure SQL has a user mapped for that identity and that the user has the required permissions. I would also check SQL firewall, private endpoint, VNet integration, and whether the failing environment uses the same identity as the one that was granted access. The error message usually tells whether this is authentication, authorization, or network access.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would separate identity acquisition from database permission. The app may acquire a token successfully and still fail because the database user does not exist or lacks rights. It may also have correct database rights but fail before SQL because network rules block the connection. For EF Core, I would check whether the runtime path and migration path use different identities or permissions. Runtime access can be least privilege, while migrations may need a separate controlled identity. I would prove the fix with a small production-safe connectivity check rather than assuming the next user request will tell me.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would keep the fix least-privileged and auditable. I would not switch back to a stored SQL password unless it is a deliberate emergency mitigation with a rollback plan. I would review identity ownership, environment separation, SQL user mapping, schema permissions, connection pooling, and transient fault behavior. I would also monitor failed login count and token acquisition errors so the team can tell identity drift from database pressure. After recovery, I would add a deployment smoke check that proves the app identity can open the intended database without granting migration-level permissions to normal request traffic.

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

Creating a managed identity but never creating a database user for it.
Using the wrong identity in staging versus production.
Fixing runtime access by granting broad database owner permissions.
Ignoring firewall or private endpoint rules.

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

Details

Cannot distinguish token acquisition from SQL authorization.
Does not inspect the actual connection string authentication mode.
Uses one powerful identity for every app and environment.
Has no plan for migrations versus runtime permissions.

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.

How do you grant an App Service identity access to Azure SQL?
What would you check if token acquisition works but SQL login fails?
How would you handle EF migrations securely?

Continue the section

Next in Azure Production Incident Debugging Essentials: Slot Config Drift

Step 11 of 15

Debug configuration drift between App Service slots

An App Service-hosted .NET API uses managed identity for Azure SQL, but login fails in production. How would you debug it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

An App Service-hosted .NET API uses managed identity for Azure SQL, but login fails in production. How would you debug it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section