Build triggers configuration in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Trigger Behavior on Branch Push

You configure a Cloud Build trigger to start a build when code is pushed to the 'main' branch. What happens if a push is made to the 'develop' branch?

A The build trigger activates and starts a build.

B The build trigger activates but the build fails immediately.

C The build trigger does not activate; no build starts.

D The build trigger activates only if the commit message contains 'build'.

💡 Hint

Triggers can be set to watch specific branches only.

A build trigger configured for the 'main' branch only activates when code is pushed to 'main'. Pushes to other branches like 'develop' do not start builds.

❓ Configuration

intermediate

YAML Trigger Configuration for Tag Push

Which YAML snippet correctly configures a Cloud Build trigger to start a build only when a tag matching 'v*' is pushed?

A

triggerTemplate:
  repoName: my-repo
  branchName: 'main'

B

triggerTemplate:
  repoName: my-repo
  branchName: 'v*'

C

triggerTemplate:
  repoName: my-repo
  tagName: 'release-*'

D

triggerTemplate:
  repoName: my-repo
  tagName: 'v*'

💡 Hint

Tags and branches use different fields in trigger configuration.

The 'tagName' field specifies tag patterns. 'v*' matches tags starting with 'v'. 'branchName' is for branches, so option D is incorrect. Option D uses a different tag pattern.

❓ Architecture

advanced

Best Trigger Setup for Multiple Environments

You have three environments: dev, staging, and production. You want builds to trigger automatically on pushes to branches 'dev', 'staging', and 'main' respectively, each deploying to its environment. What is the best way to configure Cloud Build triggers?

A Create one trigger watching all branches and use build steps to deploy based on branch name.

B Create three separate triggers, each watching one branch and deploying to its environment.

C Create one trigger watching the 'main' branch and manually deploy dev and staging builds.

D Create triggers only for 'main' and 'staging' branches; dev builds run manually.

💡 Hint

Separate triggers simplify environment-specific builds and deployments.

Having separate triggers for each branch allows clear separation of build and deployment logic per environment, reducing complexity and risk.

❓ security

advanced

Securing Build Triggers from Unauthorized Changes

How can you prevent unauthorized users from modifying Cloud Build triggers in a shared project?

A Use IAM to restrict 'Cloud Build Admin' role only to trusted users.

B Grant all users the 'Cloud Build Editor' role.

C Disable triggers and run builds manually.

D Store trigger configurations in a public GitHub repo.

💡 Hint

Control permissions carefully with IAM roles.

Only trusted users should have 'Cloud Build Admin' role to create or modify triggers. Granting broad editor roles or making configs public risks unauthorized changes.

✅ Best Practice

expert

Optimizing Build Trigger Performance

You notice your Cloud Build triggers start builds for every commit, causing long queues and high costs. Which configuration change best reduces unnecessary builds?

A Configure triggers to only activate on changes to specific paths or files.

B Increase the number of concurrent builds allowed.

C Disable triggers and run builds on a schedule.

D Use a single trigger for all branches without filters.

💡 Hint

Filtering triggers by file changes reduces builds.

By configuring triggers to only start builds when certain files or directories change, you avoid builds for irrelevant commits, improving efficiency and cost.

Practice

1. What is the main purpose of a build trigger in Google Cloud Build?

easy

A. To monitor server health

B. To manually deploy an application

C. To automatically start a build when code changes occur

D. To create a new repository

Solution

1. Step 1: Understand build triggers role

   Build triggers watch for code changes and start builds automatically.

2. Step 2: Compare options with purpose

   Only To automatically start a build when code changes occur describes automatic build start on code changes.

3. Final Answer:

   To automatically start a build when code changes occur -> Option C

4. Quick Check:

   Build trigger = auto build start [OK]

Hint: Build triggers start builds automatically on code changes [OK]

Common Mistakes:

• Confusing triggers with manual deployment
• Thinking triggers monitor servers
• Assuming triggers create repositories

2. Which of the following is the correct syntax to specify a branch filter in a Cloud Build trigger YAML?

easy

A. trigger:
branchName: "^main$"

B. trigger:
branchName: "main"

C. trigger:
branch: "main"

D. trigger:
branchFilter: "main"

Solution

1. Step 1: Identify correct branch filter syntax

   Cloud Build uses regex in branchName to filter branches.

2. Step 2: Match regex syntax for main branch

   "^main$" matches exactly the main branch name.

3. Final Answer:

   trigger: branchName: "^main$" -> Option A

4. Quick Check:

   branchName uses regex = trigger: branchName: "^main$" [OK]

Hint: Use regex in branchName to filter branches [OK]

Common Mistakes:

• Using branch instead of branchName
• Not using regex anchors ^ and $
• Using incorrect field like branchFilter

3. Given this trigger configuration snippet:

trigger:
  branchName: "^release-.*$"
  build:
    steps:
    - name: "gcr.io/cloud-builders/docker"
      args: ["build", "-t", "gcr.io/my-project/my-app:$SHORT_SHA", "."]

What happens when a commit is pushed to branch release-v1.2?

medium

A. The build fails due to syntax error

B. The build starts and tags the image with the commit SHA

C. The build starts but tags the image with 'latest'

D. The build does not start because branch name does not match

Solution

1. Step 1: Check branchName regex against branch

   Regex "^release-.*$" matches any branch starting with 'release-', so 'release-v1.2' matches.

2. Step 2: Understand build step and tagging

   The build uses $SHORT_SHA to tag the image, so image is tagged with commit SHA.

3. Final Answer:

   The build starts and tags the image with the commit SHA -> Option B

4. Quick Check:

   Branch matches regex and tags with SHA = The build starts and tags the image with the commit SHA [OK]

Hint: Regex matches branch, build tags image with commit SHA [OK]

Common Mistakes:

• Assuming branch does not match regex
• Thinking image tags as 'latest'
• Confusing syntax error with correct YAML

4. You configured a build trigger with this YAML snippet:

trigger:
  branchName: "main"
  build:
    steps:
    - name: "gcr.io/cloud-builders/gcloud"
      args: ["app", "deploy"]

But the build never starts when you push to main. What is the likely error?

medium

A. The build steps are missing the Docker build command

B. The trigger YAML is missing the substitutions field

C. The trigger must specify a tagName instead of branchName

D. branchName should be a regex like "^main$"

Solution

1. Step 1: Check branchName format in trigger

   Cloud Build expects branchName as a regex pattern, not plain string.

2. Step 2: Correct branchName to regex

   Changing branchName to "^main$" matches exactly the main branch and triggers build.

3. Final Answer:

   branchName should be a regex like "^main$" -> Option D

4. Quick Check:

   branchName needs regex = branchName should be a regex like "^main$" [OK]

Hint: branchName must be regex, not plain text [OK]

Common Mistakes:

• Using plain branch name without regex anchors
• Confusing branchName with tagName
• Thinking substitutions are mandatory

5. You want to create a build trigger that starts only when a tag matching v* is pushed, and the build should run two steps: first build a Docker image, then deploy it. Which YAML snippet correctly configures this trigger?

hard

A. trigger:
tagName: "^v.*$"
build:
steps:
- name: "gcr.io/cloud-builders/docker"
args: ["build", "-t", "gcr.io/my-project/my-app:$TAG_NAME", "."]
- name: "gcr.io/cloud-builders/gcloud"
args: ["app", "deploy"]

B. trigger:
branchName: "^v.*$"
build:
steps:
- name: "gcr.io/cloud-builders/docker"
args: ["build", "-t", "gcr.io/my-project/my-app:$TAG_NAME", "."]
- name: "gcr.io/cloud-builders/gcloud"
args: ["app", "deploy"]

C. trigger:
tagName: "v*"
build:
steps:
- name: "gcr.io/cloud-builders/gcloud"
args: ["app", "deploy"]

D. trigger:
tagName: "^v.*$"
build:
steps:
- name: "gcr.io/cloud-builders/docker"
args: ["build", "-t", "gcr.io/my-project/my-app:latest", "."]

Solution

1. Step 1: Identify correct tag filter syntax

   Use tagName with regex "^v.*$" to match tags starting with 'v'.

2. Step 2: Verify build steps order and commands

   First step builds Docker image tagged with $TAG_NAME, second step deploys app.

3. Step 3: Check for errors in other options

   trigger: branchName: "^v.*$" build: steps: - name: "gcr.io/cloud-builders/docker" args: ["build", "-t", "gcr.io/my-project/my-app:$TAG_NAME", "."] - name: "gcr.io/cloud-builders/gcloud" args: ["app", "deploy"] uses branchName instead of tagName, C misses Docker build step, D tags image as latest without deploy step.

4. Final Answer:

   trigger: tagName: "^v.*$" build: steps: - name: "gcr.io/cloud-builders/docker" args: ["build", "-t", "gcr.io/my-project/my-app:$TAG_NAME", "."] - name: "gcr.io/cloud-builders/gcloud" args: ["app", "deploy"] -> Option A

5. Quick Check:

   tagName regex and two steps build+deploy = trigger: tagName: "^v.*$" build: steps: - name: "gcr.io/cloud-builders/docker" args: ["build", "-t", "gcr.io/my-project/my-app:$TAG_NAME", "."] - name: "gcr.io/cloud-builders/gcloud" args: ["app", "deploy"] [OK]

Hint: Use tagName regex and list all build steps in order [OK]

Common Mistakes:

• Using branchName instead of tagName for tags
• Missing one of the required build steps
• Incorrect tagName regex syntax