Sample b

Structure Terraform projects using reusable modules (e.g., VPC, compute, database) instead of defining all resources in a single root configuration.
• Organize code with a clear separation between modules/ (reusable logic) and environment folders like dev/, prod/ to maintain clarity.
• Avoid code duplication by applying the DRY principle, using variables to customize modules per environment.
• Ensure each environment has isolated configurations and state to reduce blast radius and prevent accidental production impact.

• Always store Terraform state in a remote backend (e.g., S3, Terraform Cloud, Azure Storage) instead of local state to enable secure team collaboration.
• Enable state locking (e.g., DynamoDB with S3 backend) to prevent concurrent terraform apply operations and avoid race conditions.
• Never commit terraform.tfstate files to version control, as they may contain sensitive data and infrastructure mappings.
• Use separate remote state files for each environment (dev, staging, prod) to ensure isolation and reduce blast radius.
• Protect state integrity through backend versioning and access control (IAM roles, RBAC) to prevent accidental modification or corruption.

1. Never hardcode sensitive values (passwords, API keys, access keys) directly in Terraform configuration files, as this exposes credentials in version control and increases security risk. • Use secure secret management solutions such as environment variables, IAM roles, AWS Secrets Manager, HashiCorp Vault, or CI/CD secret stores to inject sensitive values securely. • Mark sensitive input variables using sensitive = true to prevent secret values from being displayed in CLI output and logs. • Ensure Terraform state files are protected, encrypted, and stored in secure remote backends, since state may contain sensitive data. • Follow the principle of least privilege by granting only the minimum required permissions to Terraform execution roles.