Terraform GCP provider setup - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Correct GCP provider block for Terraform

Which Terraform provider block correctly configures the Google Cloud provider with a specific project and region?

A

provider "google" {
  project = "my-project-id"
  region  = "us-central1"
}

B

provider "gcp" {
  project = "my-project-id"
  region  = "us-central1"
}

C

provider "google" {
  project_id = "my-project-id"
  location  = "us-central1"
}

D

provider "google" {
  project = "my-project-id"
  zone  = "us-central1"
}

💡 Hint

The official Terraform provider for Google Cloud is named "google" and uses "project" and "region" keys.

The correct provider block uses provider "google" with project and region keys. Option A uses wrong provider name, C uses incorrect keys, and D uses zone instead of region.

❓ service_behavior

intermediate

Effect of missing credentials in GCP provider

What happens when you run Terraform with a GCP provider block that does not specify credentials and no environment variables are set?

A Terraform ignores authentication and creates resources anonymously.

B Terraform fails with an authentication error indicating missing credentials.

C Terraform applies resources successfully using default application credentials.

D Terraform prompts interactively for credentials during apply.

💡 Hint

Terraform requires credentials to authenticate with GCP APIs unless default credentials are available.

If no credentials are provided in the provider block or environment, Terraform cannot authenticate and will fail with an error.

❓ Architecture

advanced

Best practice for managing multiple GCP projects in Terraform

You manage infrastructure across multiple GCP projects. Which Terraform setup best isolates configurations and credentials per project?

A Use a single Terraform configuration with multiple provider aliases, each configured with its project and credentials.

B Use one provider block with the first project and switch the project ID manually before each apply.

C Create separate Terraform workspaces for each project but use the same provider block without aliases.

D Use one provider block and pass project IDs as variables without changing credentials.

💡 Hint

Terraform provider aliases allow multiple configurations in one setup.

Using multiple provider aliases lets you configure each GCP project separately with its credentials, enabling isolated management within one Terraform codebase.

❓ security

advanced

Secure way to provide GCP credentials to Terraform

Which method is the most secure way to provide GCP credentials to Terraform for automated pipelines?

A Commit the service account JSON key file to the source code repository and reference it in Terraform provider.

B Manually enter credentials in Terraform provider block as plain text.

C Store the service account JSON key file in the pipeline environment variables as a base64 string and decode it at runtime.

D Use Google Cloud Workload Identity Federation to authenticate without storing keys.

💡 Hint

Avoid storing long-lived keys in source code or environment variables when possible.

Workload Identity Federation allows Terraform to authenticate to GCP securely without storing service account keys, reducing risk of key leakage.

🧠 Conceptual

expert

Terraform provider version constraint impact

Given this provider block snippet, what is the effect of the version constraint on Terraform provider behavior? provider "google" { version = ">= 4.0, < 5.0" project = "my-project" region = "us-east1" }

GCP

provider "google" {
  version = ">= 4.0, < 5.0"
  project = "my-project"
  region  = "us-east1"
}

A Terraform will fail to initialize because the version constraint syntax is invalid.

B Terraform will use any provider version including 5.0 and above if available.

C Terraform will only use provider versions 4.x, preventing automatic upgrades to version 5 or higher.

D Terraform ignores the version constraint and uses the latest installed provider.

💡 Hint

Version constraints control which provider versions Terraform can install and use.

The constraint ">= 4.0, < 5.0" means Terraform will use any provider version starting at 4.0 up to but not including 5.0, preventing upgrades to major version 5.