Terraform-Sap-Btp

# Terraform on SAP BTP – Best Practices & Conventions

Core Principles

Keep Terraform code minimal, modular, repeatable, secure, and auditable.

Always version control Terraform HCL and never version control generated state.

Security

Mandatory:

- Use the latest stable Terraform CLI and provider versions; upgrade proactively for security patches.

- Do NOT commit secrets, credentials, certificates, Terraform state, or plan output artifacts.

- Mark all secret variables and outputs as `sensitive = true`.

- Prefer ephemeral / write‑only provider auth (Terraform >= 1.11) so secrets never persist in state.

- Minimize sensitive outputs; emit only what downstream automation truly needs.

- Continuously scan with `tfsec`, `trivy`, `checkov` (pick at least one) in CI.

- Periodically review provider credentials, rotate keys, and enable MFA where supported.

Modularity

Structure for clarity and speed:

- Split by logical domain (e.g., entitlements, service instances) – NOT by environment.

- Use modules for reusable multi‑resource patterns only; avoid single‑resource wrapper modules.

- Keep module hierarchy shallow; avoid deep nesting and circular dependencies.

- Expose only essential cross‑module data via `outputs` (mark sensitive when required).

Maintainability

Aim for explicit > implicit.

- Comment WHY, not WHAT; avoid restating obvious resource attributes.

- Parameterize (variables) instead of hard‑coding; provide defaults only when sensible.

- Prefer data sources for external existing infra; never for resources just created in same root – use outputs.

- Avoid data sources in generic reusable modules; require inputs instead.

- Remove unused / slow data sources; they degrade plan time.

- Use `locals` for derived or repeated expressions to centralize logic.

Style & Formatting

General

- Descriptive, consistent names for resources, variables, outputs.

- snake_case for variables & locals.

- 2 spaces indentation; run `terraform fmt -recursive`.

Layout & Files

Recommended structure:

my-sap-btp-app/
├── infra/                      # Root module
│   ├── main.tf                 # Core resources (split by domain when large)
│   ├── variables.tf            # Inputs
│   ├── outputs.tf              # Outputs
│   ├── provider.tf             # Provider config(s)
│   ├── locals.tf               # Local/derived values
│   └── environments/           # Environment var files only
│       ├── dev.tfvars
│       ├── test.tfvars
│       └── prod.tfvars
├── .github/workflows/          # CI/CD (if GitHub)
└── README.md                   # Documentation

Rules:

- Do NOT create separate branches/repos/folders per environment (antipattern).

- Keep environment drift minimal; encode differences in *.tfvars files only.

- Split oversized `main.tf` / `variables.tf` into logically named fragments (e.g., `main_services.tf`, `variables_services.tf`).

Keep naming consistent.

Resource Block Organization

Order (top → bottom): optional `depends_on`, then `count`/`for_each`, then attributes, finally `lifecycle`.

- Use `depends_on` ONLY when Terraform cannot infer dependency (e.g., data source needs entitlement).

- Use `count` for optional single resource; `for_each` for multiple instances keyed by a map for stable addresses.

- Group attributes: required first, then optional; blank lines between logical sections.

- Alphabetize within a section for faster scanning.

Variables

- Every variable: explicit `type`, non‑empty `description`.

- Prefer concrete types (`object`, `map(string)`, etc.) over `any`.

- Avoid null defaults for collections; use empty lists/maps instead.

Locals

- Centralize computed or repeated expressions.

- Group related values into object locals for cohesion.

Outputs

- Expose only what downstream modules/automation consume.

- Mark secrets `sensitive = true`.

- Always give a clear `description`.

Formatting & Linting

- Run `terraform fmt -recursive` (required in CI).

- Enforce `tflint` (and opti