One Terraform configuration deploys the same stack to a dev account and a prod account in the same cloud. Compliance requires that a dev run can never authenticate into the prod account. Which approach meets the requirement?
Select an answer to reveal the explanation.
Short Explanation
If a dev run is never handed the prod key, it can't open the prod door, no matter what the code says. So keep keys out of your configuration and let each environment's run arrive with its own identity. Anything that gives one identity both doors only relies on people not making mistakes.
Full Explanation
The control that enforces separation is the identity a run authenticates with, not the configuration's logic. Leaving credentials out of the provider block and having each environment's execution context provide its own short-lived credentials, such as a pipeline job that assumes a prod-only role or an HCP Terraform workspace using dynamic provider credentials bound to that workspace, means a dev run physically lacks permission in the prod account. The same configuration serves both environments, and the cloud's access controls enforce the boundary. Aliased providers with static keys put long-lived secrets in code and let any run that selects the other alias reach prod. A single identity with rights in both accounts makes isolation depend on a variable value, which a mistake or a malicious change can flip. Committing prod keys in a tfvars file exposes them to everyone with repository access; marking variables sensitive only redacts them from CLI output and does not protect the file. Exam caveat: the stronger answer is always the one where credentials are scoped per environment and issued at run time. Operational check: attempt a dev run with its credentials against a prod resource and confirm it is denied by the cloud provider.