GCP provider setup in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Correct GCP provider block for Terraform

Which Terraform provider block correctly sets up the Google Cloud provider with project ID "my-project" and region "us-central1"?

A

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

B

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

C

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

D

provider "google" {
  project = "my-project"
  region  = "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 D matches this exactly. Option D uses wrong provider name and keys. Option D uses incorrect keys. Option D uses zone instead of region.

🧠 Conceptual

intermediate

Service Account Authentication in GCP Provider

Which option correctly describes how to authenticate Terraform with a GCP service account JSON key file?

A Include the JSON key file content directly inside the provider block under a 'credentials' attribute.

B Use the 'access_token' attribute in the provider block with the service account email.

C Set the environment variable GOOGLE_APPLICATION_CREDENTIALS to the path of the JSON key file before running Terraform.

D No authentication is needed if you run Terraform on any machine inside GCP.

💡 Hint

Terraform uses environment variables or explicit credentials file paths for authentication.

Terraform authenticates to GCP by reading the JSON key file path from the environment variable GOOGLE_APPLICATION_CREDENTIALS. Option C is correct and recommended. Option C is possible using the credentials attribute with raw JSON content or a file path, but hardcodes credentials and is not recommended for production. Option C is wrong because 'access_token' expects an OAuth token, not an email. Option C is false; authentication is always required.

❓ 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 Create separate Terraform root modules for each project, each with its own provider block and state file.

B Use a single provider block with multiple project IDs listed in an array.

C Manage all projects in one Terraform configuration with conditional resource creation.

D Use one Terraform workspace and switch the project ID in the provider block dynamically with variables.

💡 Hint

Isolating state and credentials per project reduces risk and complexity.

Option A is best practice: separate root modules per project with dedicated provider blocks and state files. This isolates credentials and state, reducing risk. Option A risks state conflicts. Option A is invalid; provider blocks do not accept arrays. Option A complicates management and risks errors.

❓ security

advanced

Least privilege principle for GCP provider service accounts

Which option best follows the least privilege principle when assigning roles to a service account used by Terraform's GCP provider?

A Assign the 'Owner' role to the service account for full access during deployment.

B Assign only the specific roles needed to create and manage the resources Terraform will handle.

C Assign the 'Editor' role to cover most resource management needs.

D Assign no roles and rely on default permissions.

💡 Hint

Grant only permissions necessary for the tasks Terraform performs.

Option B follows the least privilege principle by granting only necessary roles. Option B is too broad and risky. Option B is broad and may grant unnecessary permissions. Option B will cause failures due to lack of permissions.

❓ service_behavior

expert

Terraform GCP provider behavior with missing project attribute

What happens when you run Terraform with a GCP provider block that omits the 'project' attribute and no project is set in environment variables or default credentials?

Terraform

provider "google" {
  region = "us-east1"
}

A Terraform throws an error indicating the project ID is missing and stops execution.

B Terraform applies resources in the default project linked to the credentials automatically.

C Terraform prompts the user to input a project ID during apply.

D Terraform uses the region value as the project ID by default.

💡 Hint

The project ID is required unless set in credentials or environment.

Without a project attribute or environment variable, Terraform cannot determine the project and throws an error. It does not prompt or guess. Option A is correct. Option A is false if no default project is set. Option A does not happen. Option A is invalid.

Practice

1. What is the main purpose of the provider "google" block in a Terraform configuration for GCP?

easy

A. To define the virtual machine size in GCP

B. To create a new Google Cloud project automatically

C. To connect Terraform to your Google Cloud project

D. To set up billing information for Google Cloud

Solution

1. Step 1: Understand the role of the provider block

   The provider "google" block tells Terraform which cloud service to connect to and how.

2. Step 2: Identify what the provider configures

   It sets the connection details like project ID, region, and credentials to manage resources in GCP.

3. Final Answer:

   To connect Terraform to your Google Cloud project -> Option C

4. Quick Check:

   Provider block = Connect to GCP [OK]

Hint: Provider block always connects Terraform to the cloud service [OK]

Common Mistakes:

• Thinking provider creates resources directly
• Confusing provider with resource definitions
• Assuming provider sets billing or VM size

2. Which of the following is the correct syntax to specify the project ID in the GCP provider block in Terraform?

easy

A. project = "my-project-123"

B. project_id = "my-project-123"

C. projectName = "my-project-123"

D. projectID = "my-project-123"

Solution

1. Step 1: Recall the correct attribute name for project ID

   The official Terraform GCP provider uses project to specify the project.

2. Step 2: Check the syntax format

   The attribute is project = "my-project-123".

3. Final Answer:

   project = "my-project-123" -> Option A

4. Quick Check:

   Correct attribute is project [OK]

Hint: Use project [OK]

Common Mistakes:

• Using project_id instead of project
• Using camelCase like projectName or projectID
• Missing quotes around the project ID string

3. Given this Terraform provider block for GCP:

provider "google" {
  project     = "my-project"
  region      = "us-central1"
  credentials = file("account.json")
}

What will happen when you run terraform init?

medium

A. Terraform throws an error because the attribute project is incorrect

B. Terraform initializes and connects to the specified GCP project using the credentials file

C. Terraform ignores the credentials file and uses default credentials

D. Terraform creates a new GCP project named "my-project" automatically

Solution

1. Step 1: Check attribute names in the provider block

   The correct attribute for project ID is project, which is used here.

2. Step 2: Understand Terraform behavior on correct attributes

   Terraform initializes successfully and configures the provider using the credentials file.

3. Final Answer:

   Terraform initializes and connects to the specified GCP project using the credentials file -> Option B

4. Quick Check:

   Correct attributes allow successful init [OK]

Hint: Use exact attribute names like project to ensure smooth init [OK]

Common Mistakes:

• Assuming project is incorrect (it's the right attribute)
• Thinking Terraform auto-creates projects
• Believing init ignores credentials

4. You wrote this provider block:

provider "google" {
  project = "my-project"
  region = "us-central1"
  credentials = file("wrong-path.json")
}

When running terraform plan, you get a credentials error. What is the most likely cause?

medium

A. The credentials file path is incorrect or file does not exist

B. The project is invalid format

C. The region value is not supported by GCP

D. Terraform requires credentials to be set as environment variables only

Solution

1. Step 1: Analyze the credentials attribute

   The credentials attribute expects a valid JSON file path with service account keys.

2. Step 2: Identify the error cause

   If the file path is wrong or file missing, Terraform cannot authenticate and throws an error.

3. Final Answer:

   The credentials file path is incorrect or file does not exist -> Option A

4. Quick Check:

   Wrong credentials file path causes auth error [OK]

Hint: Check credentials file path carefully to avoid auth errors [OK]

Common Mistakes:

• Assuming region errors cause credential failures
• Thinking project format causes credential errors
• Believing credentials must be environment variables only

5. You want to configure Terraform to manage resources in two different GCP projects within the same configuration. How should you set up the provider blocks?

hard

A. Set project dynamically inside resource blocks without provider aliases

B. Use a single provider block with a list of projects

C. Create two separate Terraform configurations for each project

D. Define two provider blocks with different aliases and specify project for each

Solution

1. Step 1: Understand multi-project management in Terraform

   Terraform supports multiple provider configurations using aliases to distinguish them.

2. Step 2: Configure providers with aliases and project

   Define two provider "google" blocks with different alias names and set project for each.

3. Step 3: Reference providers in resources

   Use provider = google.alias_name in resource blocks to specify which project to use.

4. Final Answer:

   Define two provider blocks with different aliases and specify project for each -> Option D

5. Quick Check:

   Multiple projects = multiple aliased providers [OK]

Hint: Use provider aliases to manage multiple GCP projects [OK]

Common Mistakes:

• Trying to list multiple projects in one provider
• Not using aliases and causing conflicts
• Splitting into separate configs unnecessarily