How does Pydantic handle extra JSON fields, and how to configure it?

WHAT THIS TESTS: Whether you understand Pydantic v2's default data filtering behavior and how to control it via model configuration. Interviewers want to see that you know extra fields are ignored by default, not rejected, and that you can enforce strict schemas when needed.

A GOOD ANSWER COVERS: First, state the default behavior. Pydantic ignores extra fields that are not defined in the model, meaning they are dropped silently during validation and the model instance is created without them. Second, explain how to forbid extra fields. You set model_config = ConfigDict(extra='forbid') inside the model class, which causes Pydantic to raise a ValidationError if any unexpected fields are present; in FastAPI this translates to an automatic 422 response. Third, explain how to allow extra fields. You set model_config = ConfigDict(extra='allow'), which captures the extra data and stores it in the model's __pydantic_extra__ dictionary while still validating defined fields normally. Fourth, mention where this matters in FastAPI. By default, a client can send a bloated payload and FastAPI will happily accept it, which can be a security or debugging concern if you expected strict contracts.

COMMON WRONG ANSWERS: Claiming that Pydantic or FastAPI rejects extra fields by default with a 422 error. This is false; that only happens when extra='forbid' is explicitly configured. Another red flag is suggesting manual validation inside the endpoint by inspecting the raw dict instead of using Pydantic's built-in configuration. Some candidates also confuse Pydantic v1 behavior with v2; in v2 the configuration moved to model_config and ConfigDict, whereas v1 used class Config with extra fields.

LIKELY FOLLOW-UPS: How would you implement partial updates or patch endpoints with optional extra fields? What is the performance impact of allowing arbitrary extra fields on high throughput endpoints? How would you write a custom validator that behaves differently depending on whether extra fields are allowed? Can you dynamically create a model that forbids extras at runtime?

ONE CONCRETE EXAMPLE: Imagine a UserCreate model with name and email fields. A client sends a POST request with JSON containing name, email, and an unexpected is_admin flag. With the default ignore setting, Pydantic drops is_admin and creates the user, which could be dangerous if downstream code trusts the payload shape. To prevent this, you define the model with model_config = ConfigDict(extra='forbid'), and FastAPI immediately returns a 422 Unprocessable Entity before your endpoint logic ever runs.