Terraform depends_on未按预期控制GCP资源创建顺序排查

• terraform plan 输出的资源排列顺序不代表实际执行顺序，你声明的depends_on依赖规则是正常生效的，Terraform不会跳过API启用步骤直接创建Artifact Registry仓库。
• 你遇到的403报错和依赖顺序无关，根因是GCP API启用后的传播延迟，以及跨provider依赖带来的时序问题。

plan输出顺序的逻辑 #

Terraform的plan结果仅做信息展示，列表默认按资源类型、资源名的字典序排序，和实际执行优先级没有关联。Terraform在apply阶段会基于所有显式depends_on规则、资源属性引用关系生成依赖拓扑图，严格按照拓扑顺序执行资源操作，无依赖关系的资源会并行调度。你可以通过terraform graph命令输出完整的依赖链路，就能验证你配置的「启用cloudresourcemanager → 启用artifactregistry → 创建仓库」的依赖链是完全正确的。

403报错的真实原因 #

GCP的API启用操作是异步生效的：当你调用API启用接口返回成功时，仅代表GCP已收到启用请求，配置需要同步到全球所有GCP后端节点，这个传播过程通常需要10秒到5分钟不等，期间调用依赖该API的其他接口就会返回「API未启用」的403错误。
另外你的配置存在跨provider依赖的问题：两个google_project_service资源使用默认的google provider，而google_artifact_registry_repository资源指定了google-beta provider，depends_on仅能保证API资源的创建请求先于仓库资源发起，无法让google-beta provider等待API完全传播生效后再发请求，很容易踩中传播空窗期报错。

• 给google_project_service资源配置超时时间，让Terraform等待API确认激活后再进入下一步：

resource "google_project_service" "cloud_resource_manager" {
  project = var.tf_project_id
  service = "cloudresourcemanager.googleapis.com"
  disable_dependent_services = true

  timeouts {
    create = "300s"
    update = "400s"
  }
}

resource "google_project_service" "artifact_registry" {
  project = var.tf_project_id
  service = "artifactregistry.googleapis.com"
  disable_dependent_services = true
  depends_on = [google_project_service.cloud_resource_manager]

  timeouts {
    create = "300s"
    update = "400s"
  }
}

• 统一资源使用的provider：当前GA版google provider已经完整支持Artifact Registry资源，不需要强制使用google-beta provider，把仓库资源的provider = google-beta配置移除即可，避免跨provider的时序问题。
• 如果仍偶发报错，可以增加固定缓冲等待API传播：

resource "time_sleep" "wait_gcp_api" {
  create_duration = "60s"
  depends_on = [google_project_service.artifact_registry]
}

resource "google_artifact_registry_repository" "el" {
  project = var.tf_project_id
  location = var.region
  repository_id = "el"
  description = "Repository for extract/load docker images"
  format = "DOCKER"
  depends_on = [time_sleep.wait_gcp_api]
}

内容的提问来源于stack exchange，提问作者BigBoy1337