Least privilege for Terraform service accounts - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a service account with a descriptive name.

Terraform

resource "google_service_account" "terraform_sa" {
  account_id   = "[1]"
  display_name = "Terraform Service Account"
}

Drag options to blanks, or click blank then click option'

Aterraform-sa

Buser-account

Cdefault

Dadmin-sa

Attempts:

3 left

💡 Hint

Common Mistakes

Using generic or unrelated account IDs.

Using names that are too long or complex.

The account_id should be a clear identifier like terraform-sa to represent the Terraform service account.

2fill in blank

medium

Complete the code to assign the minimal IAM role for Terraform to manage Compute Engine instances.

Terraform

resource "google_project_iam_member" "terraform_compute_role" {
  project = var.project_id
  role    = "[1]"
  member  = "serviceAccount:${google_service_account.terraform_sa.email}"
}

Drag options to blanks, or click blank then click option'

Aroles/compute.instanceAdmin.v1

Broles/editor

Croles/viewer

Droles/owner

Attempts:

3 left

💡 Hint

Common Mistakes

Assigning overly broad roles like 'roles/owner'.

Assigning read-only roles that don't allow changes.

The role roles/compute.instanceAdmin.v1 grants Terraform the least privilege needed to manage Compute Engine instances.

3fill in blank

hard

Fix the error in the IAM binding by completing the role with the correct least privilege for Terraform to manage Cloud Storage buckets.

Terraform

resource "google_project_iam_member" "terraform_storage_role" {
  project = var.project_id
  role    = "[1]"
  member  = "serviceAccount:${google_service_account.terraform_sa.email}"
}

Drag options to blanks, or click blank then click option'

Aroles/storage.admin

Broles/storage.objectViewer

Croles/storage.viewer

Droles/storage.objectAdmin

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'roles/storage.admin' which is too broad.

Using 'roles/storage.viewer' which is read-only.

The roles/storage.objectAdmin role allows Terraform to create, update, and delete objects in Cloud Storage buckets, which is the least privilege needed for managing bucket contents.

4fill in blank

hard

Fill both blanks to create a custom IAM role with minimal permissions for Terraform to manage Compute Engine instances.

Terraform

resource "google_project_iam_custom_role" "terraform_custom_role" {
  role_id     = "terraformComputeRole"
  title       = "Terraform Compute Role"
  description = "Custom role with least privilege for Terraform Compute management"
  permissions = [
    "[1]",
    "[2]"
  ]
  project     = var.project_id
}

Drag options to blanks, or click blank then click option'

Acompute.instances.create

Bcompute.instances.delete

Ccompute.instances.start

Dcompute.instances.get

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing permissions that do not allow instance creation or deletion.

Including unnecessary permissions that increase privilege.

The permissions compute.instances.create and compute.instances.delete allow Terraform to create and delete instances, covering essential management actions with least privilege.

5fill in blank

hard

Fill all three blanks to define a minimal IAM policy binding for Terraform service account to manage networking resources.

Terraform

resource "google_project_iam_member" "terraform_network_role" {
  project = var.project_id
  role    = "[1]"
  member  = "serviceAccount:${google_service_account.terraform_sa.email}"
  condition {
    title       = "Limit to VPC networks"
    description = "Restrict permissions to VPC network management"
    expression  = "resource.name.startsWith('projects/${var.project_id}/global/networks/') && resource.type == '[2]' && request.time < timestamp('[3]')"
  }
}

Drag options to blanks, or click blank then click option'

Aroles/compute.networkAdmin

Bcompute.networks

C2025-01-01T00:00:00Z

Droles/compute.viewer

Attempts:

3 left

💡 Hint

Common Mistakes

Using overly broad roles like 'roles/compute.viewer' for management tasks.

Incorrect resource type or timestamp format in the condition.

The role roles/compute.networkAdmin grants Terraform the ability to manage networks. The condition restricts the resource type to compute.networks and limits the permission validity until 2025-01-01T00:00:00Z, enforcing least privilege and time-bound access.

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