Skip to content
Sarj Code Standards

no-duplicate-deployment-literal

Share repeated cloud deployment values through variables, locals or resource references.

Why

Repeating deployment identities and locations scatters configuration across resource declarations and makes coordinated changes harder to review.

Fix

Use an existing resource/data reference, a shared local for a fixed deployment value, or a module input for a caller-configured value. Keep independently configurable scopes independent.

Examples

Before — flagged Cloudflare resources repeat their deployment account
main.tf
resource "cloudflare_r2_bucket" "a" { account_id = "example-account" }
resource "cloudflare_r2_bucket" "b" { account_id = "example-account" }
After — preferred Cloudflare resources share their typed account input
main.tf
variable "account_id" { type = string }
resource "cloudflare_r2_bucket" "a" { account_id = var.account_id }
resource "cloudflare_r2_bucket" "b" { account_id = var.account_id }
Before — flagged Resources repeat one deployment project
main.tf
resource "google_storage_bucket" "a" { project = "example-project" }
resource "google_cloud_run_v2_job" "b" { project = "example-project" }
After — preferred Resources use their shared deployment input
main.tf
variable "project_id" { type = string }
resource "google_storage_bucket" "a" { project = var.project_id }
resource "google_cloud_run_v2_job" "b" { project = var.project_id }