How do you manage environment-specific connection strings and why is hardcoding bad?

WHAT THIS TESTS: This question evaluates whether you treat configuration as separate from code and whether you understand the operational and security risks of embedding secrets in an application binary. A senior candidate should demonstrate familiarity with environment-based injection, secret stores, and platform-specific authentication patterns rather than manual credential juggling.

A GOOD ANSWER COVERS: Four things in order. First, the mechanism for environment-specific values: environment variables, a secret store such as Azure Key Vault or AWS Secrets Manager, or encrypted configuration files like appsettings.Production.json that are deployed by the pipeline and never committed to source control. Second, the security argument against hardcoding: strings compiled into assemblies can be read using ILDASM to view CIL, and any secret checked into git remains in history even after deletion. Third, runtime protection: setting Persist Security Info=False so that credentials are discarded after the connection opens, and encrypting configuration files at rest. Fourth, authentication best practices: preferring password-less methods such as Managed Identities for Azure SQL or Windows Authentication with integrated security, eliminating passwords from the string entirely.

COMMON WRONG ANSWERS: Saying you would use a switch statement or preprocessor directives to pick the string per environment, which still embeds secrets in code. Storing plaintext passwords in appsettings files and checking them into Git. Proposing Universal Data Link files, which are stored in clear text and cannot be encrypted using .NET. Claiming that staging credentials do not matter because the data is not production; attackers routinely pivot from staging to production.

LIKELY FOLLOW-UPS: How would you rotate a compromised connection string without redeploying? How do you handle local developer machines that cannot reach the corporate secret store? What is the blast radius if the CI/CD pipeline itself is compromised and has vault read access? When is it acceptable to use a connection string builder, and how do you prevent connection string injection from user input?

ONE CONCRETE EXAMPLE: In a .NET application deployed to Azure, you would store the connection string as a secret in Azure Key Vault, reference it via the Azure Key Vault configuration provider, and use a Managed Identity so the connection string contains no password. For local development, you use the ASP.NET Core Secret Manager tool or a developer-specific Key Vault access policy so that appsettings.Development.json only contains non-secret overrides. The pipeline injects the vault URI via an environment variable, and the runtime resolves the secret during startup.