The standalone configuration to emit when the user has no existing Terraform project. When they do,
take only the resources below the provider blocks and add them to what they already have.
Placeholders to replace before writing the file:
Placeholder
Source
<USER_FOLDER_IDS>
Phase 2 - a complete HCL list, e.g. ["123456789"], or [] when none. The placeholder replaces the whole expression, brackets included
<USER_PROJECT_IDS>
Phase 2 - a complete HCL list, e.g. ["my-proj"], or [] when none
<HOST_PROJECT_ID>
Phase 2 - the project that holds the service account
# No root variables hold the Datadog keys. The provider reads them from DD_API_KEY and DD_APP_KEY in the# environment, so there is nothing for Terraform to record: no variable value in state, none in a saved# plan, and no `-var=` on any command line. This also means an existing project needs no variable changes.locals { folder_ids = <USER_FOLDER_IDS> project_ids = <USER_PROJECT_IDS> project_id = "<HOST_PROJECT_ID>" # roles/browser is deliberately NOT here: Datadog requires it only in the service account's own # (host) project, and it is granted separately below. Granting it to every monitored scope both # over-permissions them and misses the host project when the host is out of monitoring scope. roles_to_assign = [ "roles/cloudasset.viewer", "roles/compute.viewer",
Projects only (no folders). Delete the folder_ids local, the google_projects.folder_projects
data source, google_folder_iam_member.datadog_gcp_service_account_folder_roles, and its depends_on
entry; simplify all_project_ids to toset(local.project_ids).
Folders only. Keep folder_ids populated and set project_ids to the expanded list of descendant
projects gathered during discovery. Do not leave project_ids = []: folder-scope roles are inherited by
every current and future project, but google_project_service only enables APIs for projects it is told
about, so an empty list silently ships an integration that collects nothing.
The host project is not in scope. The host project only needs to hold the service account, so it
can stay out of project_ids and out of the monitored folders if the user doesn’t want its metrics
collected. Keep google_project_service.host_project_iam_apis in that case - it is what enables
iam.googleapis.com / iamcredentials.googleapis.com there, and without it service-account creation or
impersonation fails in a project that no other resource touches. Keep
google_project_iam_member.datadog_host_project_browser for the same reason - roles/browser is required
in the service account’s own project regardless of whether that project is monitored.
Nested folders.data.google_projects matches on immediate parent only, so a project inside a
sub-folder inherits the folder IAM grants but never gets API enablement. Either list each nested folder
in folder_ids or name those projects in project_ids - do not assume one top-level folder covers a
deep hierarchy.
Explicit google provider config. The template relies on ambient application-default credentials.
Add provider "google" { project = local.project_id } if the user needs a pinned project or an
impersonated identity.