Manage dev, staging, and prod configs in a large FastAPI app

WHAT THIS TESTS: The interviewer wants to know if you can keep environment-specific values and secrets out of source code while maintaining type safety and testability. They are looking for familiarity with pydantic-settings, environment variable patterns, and dependency injection in FastAPI. The question also surfaces whether you understand the performance implication of repeatedly parsing configuration and how to handle secrets in production versus local development.

A GOOD ANSWER COVERS: First, define a single Settings class using pydantic-settings that declares fields with types and defaults where appropriate, reading from environment variables. Second, use python-dotenv so local developers can keep a .env file that is gitignored while staging and production receive variables directly from the container orchestrator or host. Third, cache the settings instance with functools.lru_cache so the application parses configuration once at startup rather than on every request. Fourth, expose the settings to the application through a FastAPI dependency so path operations can access config via dependency injection while remaining easy to override in tests. Fifth, distinguish between non-sensitive config and secrets, noting that secrets in production should come from a secret manager or Docker secrets rather than being committed or logged.

COMMON WRONG ANSWERS: A major red flag is hardcoding environment checks like if env equals production scattered across modules, which makes the codebase brittle and difficult to test. Another mistake is importing settings directly as a global singleton without caching, which can cause repeated file system or parsing overhead. Staging and production credentials should never live in a committed .env file or in source control. Also, avoid suggesting one giant untyped dictionary loaded from JSON without validation, because that defeats the purpose of using FastAPI and Pydantic for type safety.

LIKELY FOLLOW-UPS: The interviewer may ask how you would rotate a database password without restarting the application, which probes whether you understand that lru_cache makes the config immutable after startup. They might also ask how you would test routes that depend on settings, where the correct pattern is overriding the dependency in the test client. Another follow-up is how to handle nested or prefixed environment variables, which pydantic-settings supports through model_config settings.

ONE CONCRETE EXAMPLE: Imagine a Settings class with fields for database_url, secret_key, and debug. In development, a .env file sets database_url to a local Postgres instance and debug to True. In production, the container platform injects database_url from a secret vault and debug defaults to False. The application creates the settings once with lru_cache and injects it into routes. During testing, the test suite overrides the settings dependency with a test-specific database_url so tests never touch production data.