Why does this backend configuration not follow best practices?

Why does this backend configuration not follow best practices?

• A. You should not store credentials in Terraform Configuration
• B. You should use the local enhanced storage backend whenever possible
• C. An alias meta-argument should be included in backend blocks whenever possible
• D. The backend configuration should contain multiple credentials so that more than one user can execute terraform plan and terraform apply

Answer: (A)

Credentials should never be stored in Terraform configuration. Placing sensitive keys or secrets in the backend block means they become part of the codebase, which can be checked into version control, shared with others, or exposed in logs and CI pipelines. That creates a risk that anyone with access to the code can access and potentially modify your remote state. The best approach is to supply credentials through secure external mechanisms. For example, use environment variables (like AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY), a shared credentials file with a named profile, or an IAM role via instance profiles or CI runners. The backend configuration should focus on non-sensitive details needed to reach the remote state (such as the bucket, region, key, and encryption or locking settings), while credentials are provided by these external, auditable sources. This keeps access to your state secure, makes automation safer, and allows for proper rotation and least-privilege controls. The other options don’t address credential security in the same robust way.

Credentials should never be stored in Terraform configuration. Placing sensitive keys or secrets in the backend block means they become part of the codebase, which can be checked into version control, shared with others, or exposed in logs and CI pipelines. That creates a risk that anyone with access to the code can access and potentially modify your remote state.

The best approach is to supply credentials through secure external mechanisms. For example, use environment variables (like AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY), a shared credentials file with a named profile, or an IAM role via instance profiles or CI runners. The backend configuration should focus on non-sensitive details needed to reach the remote state (such as the bucket, region, key, and encryption or locking settings), while credentials are provided by these external, auditable sources.

This keeps access to your state secure, makes automation safer, and allows for proper rotation and least-privilege controls. The other options don’t address credential security in the same robust way.