Concept questionEasy~5 minASP.NET Core Framework / 6 of 26

Interview question

What is model binding in ASP.NET Core, and where can it cause bugs?

What is model binding in ASP.NET Core APIs?

Explains how route values, query strings, headers, and request bodies become typed endpoint input.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Model binding is how ASP.NET Core reads data from the HTTP request and maps it into action parameters or DTOs. The data can come from route values, query strings, headers, forms, or the request body. Binding gives the endpoint typed input, such as an id, a filter object, or a create request. A bound object can still be invalid, so validation is a separate step.

Full answer below

Practice focus

Binding sources, request DTOs, input boundaries, validation separation, malformed clients, and default-value pitfalls.

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 matters
Model binding looks simple, but it is the first place user input enters typed application code. Good answers separate binding from validation and mention real bugs from defaults, nullability, and ambiguous sources.
Model binding is how ASP.NET Core reads data from the HTTP request and maps it into action parameters or DTOs. The data can come from route values, query strings, headers, forms, or the request body. Binding gives the endpoint typed input, such as an id, a filter object, or a create request. A bound object can still be invalid, so validation is a separate step.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
In practice, I try to make binding sources obvious. For GET /orders/{id}?includeLines=true, the ID comes from the route and includeLines comes from the query string. For POST /orders, the request DTO comes from the body. The trade-off is convenience versus hidden behavior: automatic binding is helpful, but default values or nullable fields can hide missing client input unless validation and tests catch it.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I define binding behavior deliberately for every public boundary. I use dedicated request DTOs, explicit sources where ambiguity is possible, and nullable types when absence has meaning instead of letting CLR defaults pretend the client sent a value. I cap collection and body sizes, reject unsupported content types, and avoid binding directly to entities because that exposes server-owned fields. Contract tests cover malformed JSON, missing versus explicit null, invalid enum and date formats, repeated query values, and empty bodies. Binding errors return one consistent ProblemDetails shape without echoing sensitive input, and metrics separate malformed requests from failures inside application logic.

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 a bound object is valid.
Binding directly to EF entities.
Letting default values hide missing input.
Mixing route, query, and body data without clear rules.
Not testing malformed requests.

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

Details

Cannot distinguish binding from validation.
Does not know common binding sources.
Ignores nullable/default-value behavior.
Trusts client input after binding succeeds.

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.

When would you use [FromRoute], [FromQuery], or [FromBody] explicitly?
What happens if JSON is malformed?
Why avoid binding directly to EF entities?
How do nullable reference types affect request DTOs?

Interviewer notesInterviewerInterviewer notesWhat the interviewer is listening for.Open details

Details

Strong answers separate transport conversion from validation and describe bugs caused by binding behavior.

Recruiter notesRecruiterRecruiter notesHow to frame the answer for screening conversations.Open details

Details

This is a hands-on ASP.NET Core API topic. It reveals whether the candidate understands request input beyond happy-path JSON.

Continue the section

Next in ASP.NET Core Framework: DI Lifetimes

Step 7 of 26

How do dependency injection lifetimes affect ASP.NET Core APIs?

Opening drill

Concept questionEasy~5 minASP.NET Core Framework / 6 of 26

Interview question

What is model binding in ASP.NET Core, and where can it cause bugs?

What is model binding in ASP.NET Core APIs?

Explains how route values, query strings, headers, and request bodies become typed endpoint input.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Binding sources, request DTOs, input boundaries, validation separation, malformed clients, and default-value pitfalls.

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 matters
Model binding looks simple, but it is the first place user input enters typed application code. Good answers separate binding from validation and mention real bugs from defaults, nullability, and ambiguous sources.
Model binding is how ASP.NET Core reads data from the HTTP request and maps it into action parameters or DTOs. The data can come from route values, query strings, headers, forms, or the request body. Binding gives the endpoint typed input, such as an id, a filter object, or a create request. A bound object can still be invalid, so validation is a separate step.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
In practice, I try to make binding sources obvious. For GET /orders/{id}?includeLines=true, the ID comes from the route and includeLines comes from the query string. For POST /orders, the request DTO comes from the body. The trade-off is convenience versus hidden behavior: automatic binding is helpful, but default values or nullable fields can hide missing client input unless validation and tests catch it.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I define binding behavior deliberately for every public boundary. I use dedicated request DTOs, explicit sources where ambiguity is possible, and nullable types when absence has meaning instead of letting CLR defaults pretend the client sent a value. I cap collection and body sizes, reject unsupported content types, and avoid binding directly to entities because that exposes server-owned fields. Contract tests cover malformed JSON, missing versus explicit null, invalid enum and date formats, repeated query values, and empty bodies. Binding errors return one consistent ProblemDetails shape without echoing sensitive input, and metrics separate malformed requests from failures inside application logic.

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 a bound object is valid.
Binding directly to EF entities.
Letting default values hide missing input.
Mixing route, query, and body data without clear rules.
Not testing malformed requests.

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

Details

Cannot distinguish binding from validation.
Does not know common binding sources.
Ignores nullable/default-value behavior.
Trusts client input after binding succeeds.

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.

When would you use [FromRoute], [FromQuery], or [FromBody] explicitly?
What happens if JSON is malformed?
Why avoid binding directly to EF entities?
How do nullable reference types affect request DTOs?

Interviewer notesInterviewerInterviewer notesWhat the interviewer is listening for.Open details

Details

Strong answers separate transport conversion from validation and describe bugs caused by binding behavior.

Recruiter notesRecruiterRecruiter notesHow to frame the answer for screening conversations.Open details

Details

This is a hands-on ASP.NET Core API topic. It reveals whether the candidate understands request input beyond happy-path JSON.

Continue the section

Next in ASP.NET Core Framework: DI Lifetimes

Step 7 of 26

How do dependency injection lifetimes affect ASP.NET Core APIs?

What is model binding in ASP.NET Core, and where can it cause bugs?

Practice focus

Answer path

Why this matters

Review signals

Follow-up prompts

Continue the section

What is model binding in ASP.NET Core, and where can it cause bugs?

Practice focus

Answer path

Why this matters

Review signals

Follow-up prompts

Continue the section