Least privilege for Terraform service accounts - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ security

intermediate

Identify the least privilege IAM role for Terraform to manage Compute Instances

You want to give a Terraform service account permission to create, update, and delete Compute Engine instances only. Which IAM role grants the least privilege for this task?

A roles/editor

B roles/compute.admin

C roles/compute.instanceAdmin.v1

D roles/owner

💡 Hint

Look for the role that limits permissions to managing instances only, not the entire project.

roles/compute.instanceAdmin.v1 allows managing Compute Engine instances without broader project permissions. Other roles like compute.admin or owner have more permissions than needed.

✅ Best Practice

intermediate

Choose the best practice for Terraform service account key management

Which practice is best to securely manage Terraform service account keys?

A Use short-lived credentials and rotate keys regularly, storing them in a secure secrets manager

B Create long-lived service account keys and store them in Terraform code repository

C Share service account keys with all team members via email

D Use the default Compute Engine service account without restrictions

💡 Hint

Think about minimizing risk if keys are exposed.

Short-lived credentials and regular rotation reduce risk. Storing keys in a secure secrets manager prevents accidental exposure. Avoid sharing keys openly or using default accounts with broad permissions.

❓ Configuration

advanced

Determine the Terraform IAM binding for least privilege on Cloud Storage buckets

You want a Terraform service account to only read and write objects in a specific Cloud Storage bucket. Which IAM binding configuration grants the least privilege?

Terraform

resource "google_storage_bucket_iam_member" "terraform_sa_access" {
  bucket = "my-terraform-bucket"
  role   = role
  member = "serviceAccount:[e-mail]"
}

A role = "roles/storage.objectAdmin"

B role = "roles/storage.admin"

C role = "roles/storage.objectViewer"

D role = "roles/storage.objectCreator"

💡 Hint

Consider which role allows both reading and writing objects but not managing the bucket itself.

roles/storage.objectAdmin allows read and write access to objects in the bucket without permissions to manage bucket settings. Other roles either allow only read, only write, or full bucket management.

❓ Architecture

advanced

Select the best architecture to enforce least privilege for Terraform across multiple projects

You manage multiple GCP projects and want Terraform service accounts to have least privilege access only to their assigned projects. What architecture best supports this?

A Use user credentials instead of service accounts for Terraform

B Create separate service accounts per project with scoped IAM roles limited to each project

C Use a single service account with editor role in the organization

D Create one service account with owner role in all projects

💡 Hint

Think about isolating permissions per project to reduce risk.

Separate service accounts per project with scoped roles limit blast radius if credentials are compromised. Using one account with broad roles increases risk. User credentials are not recommended for automation.

❓ service_behavior

expert

What happens if Terraform service account lacks permission to create a resource?

Terraform runs a plan and apply to create a Compute Engine instance, but the service account lacks the required IAM permission. What is the expected behavior?

A Terraform applies changes partially and skips the resource without error

B Terraform silently ignores the missing permission and logs a warning

C Terraform creates the resource with limited features

D Terraform fails the apply step with a permission denied error and stops execution

💡 Hint

Consider how Terraform handles errors during resource creation.

Terraform stops and reports an error if the service account lacks permissions to create a resource. It does not partially apply or silently ignore permission issues.

Practice

1. What does the principle of least privilege mean for Terraform service accounts?

easy

A. Give only the permissions Terraform needs to do its job

B. Give Terraform full admin access to all cloud resources

C. Allow Terraform to access resources only during business hours

D. Share Terraform service account credentials with all team members

Solution

1. Step 1: Understand least privilege concept

   Least privilege means giving only the minimum permissions needed to perform a task.

2. Step 2: Apply to Terraform service accounts

   Terraform service accounts should have only the permissions required to manage infrastructure, nothing more.

3. Final Answer:

   Give only the permissions Terraform needs to do its job -> Option A

4. Quick Check:

   Least privilege = minimal needed permissions [OK]

Hint: Least privilege means minimal permissions only [OK]

Common Mistakes:

• Giving Terraform full admin rights unnecessarily
• Sharing credentials widely
• Setting time-based access without need

2. Which Terraform configuration snippet correctly assigns least privilege to a service account for managing only compute instances?

easy

A. resource "google_project_iam_member" "compute_admin" {
project = var.project_id
role = "roles/compute.admin"
member = "serviceAccount:${var.service_account_email}"
}

B. resource "google_project_iam_member" "storage_admin" {
project = var.project_id
role = "roles/storage.admin"
member = "serviceAccount:${var.service_account_email}"
}

C. resource "google_project_iam_member" "viewer" {
project = var.project_id
role = "roles/viewer"
member = "serviceAccount:${var.service_account_email}"
}

D. resource "google_project_iam_member" "editor" {
project = var.project_id
role = "roles/editor"
member = "serviceAccount:${var.service_account_email}"
}

Solution

1. Step 1: Identify the role for compute instance management

   The role "roles/compute.admin" allows managing compute instances specifically.

2. Step 2: Match the role to the service account in Terraform

   The snippet assigns "roles/compute.admin" to the service account, limiting permissions to compute resources only.

3. Final Answer:

   The snippet assigning roles/compute.admin to the service account -> Option A

4. Quick Check:

   Assign specific roles, not broad ones [OK]

Hint: Match role to exact resource type needed [OK]

Common Mistakes:

• Using broad roles like editor or admin unnecessarily
• Assigning unrelated roles like storage.admin
• Using viewer role which is read-only

3. Given this Terraform IAM binding snippet, what is the effective permission scope for the service account?

resource "google_project_iam_member" "sa_role" {
  project = "my-project"
  role    = "roles/storage.objectViewer"
  member  = "serviceAccount:[e-mail]"
}

medium

A. Full access to all storage buckets and objects

B. No access to storage resources

C. Write access to storage buckets

D. Read-only access to storage objects only

Solution

1. Step 1: Understand the role assigned

   The role "roles/storage.objectViewer" grants read-only access to storage objects.

2. Step 2: Determine permission scope

   This role does not allow writing or bucket management, only viewing objects.

3. Final Answer:

   Read-only access to storage objects only -> Option D

4. Quick Check:

   roles/storage.objectViewer = read-only object access [OK]

Hint: Check role name keywords: viewer means read-only [OK]

Common Mistakes:

• Confusing viewer with admin or editor roles
• Assuming bucket write permissions
• Thinking full storage access is granted

4. You wrote this Terraform code to assign a role to a service account but get an error:

resource "google_project_iam_member" "sa_role" {
  project = var.project_id
  role    = "roles/compute.viewer"
  member  = "serviceAccount:${var.service_account_email}"
  member  = "serviceAccount:[e-mail]"
}

What is the problem?

medium

A. Role 'roles/compute.viewer' does not exist

B. Duplicate 'member' keys cause a syntax error

C. Service account email format is invalid

D. Project ID variable is missing

Solution

1. Step 1: Check Terraform resource syntax

   Terraform resource blocks cannot have duplicate keys; 'member' is repeated twice here.

2. Step 2: Understand correct way to assign multiple members

   To assign multiple members, use 'google_project_iam_binding' or multiple resources, not duplicate keys.

3. Final Answer:

   Duplicate 'member' keys cause a syntax error -> Option B

4. Quick Check:

   Duplicate keys in resource block = syntax error [OK]

Hint: No duplicate keys in Terraform blocks [OK]

Common Mistakes:

• Using duplicate keys instead of lists or multiple resources
• Assuming role name is invalid without checking
• Ignoring variable definitions

5. You want to create a Terraform service account with least privilege to manage only network resources in a Google Cloud project. Which approach is best?

hard

A. Assign the role 'roles/owner' to the service account temporarily

B. Assign the role 'roles/editor' to the service account for all resources

C. Assign the role 'roles/compute.networkAdmin' to the service account only

D. Assign no roles and rely on default permissions

Solution

1. Step 1: Identify the role for network management

   The role 'roles/compute.networkAdmin' grants permissions to manage network resources only.

2. Step 2: Apply least privilege principle

   Assigning only this role limits the service account to network tasks, avoiding broad permissions.

3. Step 3: Avoid broad or no permissions

   Roles like 'editor' or 'owner' are too broad; no roles means no access.

4. Final Answer:

   Assign the role 'roles/compute.networkAdmin' to the service account only -> Option C

5. Quick Check:

   Least privilege = specific role only [OK]

Hint: Pick the narrowest role matching needed tasks [OK]

Common Mistakes:

• Using broad roles like editor or owner
• Not assigning any role and expecting access
• Assigning multiple unrelated roles