Modules for reusability in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Understanding Module Outputs in GCP Terraform

You have a Terraform module that creates a Google Cloud Storage bucket and outputs its name. What will be the value of module.bucket.bucket_name after applying the configuration?

GCP

module "bucket" {
  source = "./modules/gcs_bucket"
  bucket_name = "my-app-bucket"
}

output "bucket_name" {
  value = module.bucket.bucket_name
}

A "bucket_name"

B Throws an error because output is not defined

C "my-app-bucket"

D null

💡 Hint

Think about what the module outputs and how outputs are accessed.

The module outputs the bucket name as defined inside it. Accessing module.bucket.bucket_name returns the string "my-app-bucket".

❓ Configuration

intermediate

Module Variable Scope in GCP Terraform

Given a Terraform module that defines a variable region with a default value, what will be the region used if the module is called without specifying region?

GCP

variable "region" {
  type    = string
  default = "us-central1"
}

resource "google_compute_instance" "vm" {
  name         = "vm-instance"
  machine_type = "e2-medium"
  zone         = "${var.region}-a"
}

A "us-east1"

B null

C Throws an error because region is not passed

D "us-central1"

💡 Hint

Consider the default value behavior of variables in Terraform modules.

If a variable has a default value and is not overridden, Terraform uses the default value.

❓ security

advanced

Securing Module Inputs in GCP Terraform

You want to ensure that a sensitive variable like a service account key is not exposed in Terraform logs or state files when passed to a module. Which approach correctly secures this sensitive input?

A Declare the variable with <code>type = string</code> and <code>sensitive = true</code> in the module and pass the key as input.

B Encrypt the key manually and pass the encrypted string as input without marking it sensitive.

C Store the key in a public GitHub repo and reference it in the module input.

D Pass the key as a plain string variable without any special flags.

💡 Hint

Think about Terraform's built-in support for sensitive variables.

Marking variables as sensitive = true prevents them from being shown in logs and state outputs, protecting secrets.

❓ service_behavior

advanced

Module Reuse Impact on Resource Naming in GCP Terraform

You reuse a module twice in your Terraform configuration to create two Google Cloud Storage buckets. Both module calls use the same bucket_name input. What will happen when you apply this configuration?

A Terraform will throw an error due to duplicate resource names.

B Both buckets will be created with the same name successfully.

C Terraform will create only one bucket and ignore the second.

D Terraform will append a suffix to the second bucket name automatically.

💡 Hint

Consider how resource names must be unique in GCP and Terraform behavior on duplicates.

GCP requires unique bucket names globally. Terraform will error if two resources try to create buckets with the same name.

✅ Best Practice

expert

Designing Reusable Modules for Multi-Environment Deployments in GCP

You are designing a Terraform module to deploy a GCP Compute Engine instance. You want to reuse this module for multiple environments (dev, staging, prod) with different configurations. Which design approach best supports this reuse while following best practices?

A Create separate modules for each environment with hardcoded values inside each module.

B Use input variables for all environment-specific settings and avoid hardcoding any values inside the module.

C Use environment variables outside Terraform to switch configurations and keep the module static.

D Hardcode production values in the module and override them only for dev and staging.

💡 Hint

Think about how to keep modules flexible and maintainable across environments.

Using input variables for environment-specific settings allows one module to be reused safely and clearly for multiple environments.