Cloud Build for CI/CD in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Cloud Build trigger creation output

What is the output when you run this command to create a Cloud Build trigger for a GitHub repo?

GCP

gcloud beta builds triggers create github --repo-name=my-repo --repo-owner=my-user --branch-pattern=main --build-config=cloudbuild.yaml

A Created trigger [my-repo-trigger] for repository [my-user/my-repo] on branch [main].

B ERROR: (gcloud.beta.builds.triggers.create.github) argument --repo-name: Must be specified.

C Trigger creation failed: branch pattern 'main' is invalid.

D Permission denied: User does not have roles/cloudbuild.builds.editor.

💡 Hint

Check the command syntax and required flags for creating a GitHub trigger.

The command correctly creates a trigger for the GitHub repo on the main branch using the specified build config file.

❓ Configuration

intermediate

Cloud Build YAML step syntax

Which Cloud Build YAML snippet correctly defines a build step that runs a Docker build command?

A

steps:
- executor: 'gcr.io/cloud-builders/docker'
  params: ['build', '-t', 'gcr.io/my-project/my-image', '.']

B

]'.' ,'egami-ym/tcejorp-ym/oi.rcg' ,'t-' ,'dliub'[ :sgra  
'rekcod/sredliub-duolc/oi.rcg' :eman -
:spets

C

steps:
- container: 'gcr.io/cloud-builders/docker'
  run: ['build', '-t', 'gcr.io/my-project/my-image', '.']

D

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project/my-image', '.']

💡 Hint

Look for the correct keys for specifying the container and arguments in Cloud Build steps.

The 'name' key specifies the container image, and 'args' lists the command arguments. Other keys like 'image' or 'container' are invalid in Cloud Build YAML.

🔀 Workflow

advanced

Cloud Build multi-step workflow behavior

Given this Cloud Build YAML with two steps, what happens if the first step fails?

GCP

steps:
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['app', 'deploy']
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['apply', '-f', 'deployment.yaml']

A The build retries the first step twice before running the second step.

B Both steps run regardless of the first step's success or failure.

C The build stops immediately after the first step fails; the second step does not run.

D The second step runs only if the first step succeeds, but the build does not stop on failure.

💡 Hint

Consider the default behavior of Cloud Build when a step fails.

Cloud Build stops the build immediately if any step fails, so subsequent steps do not run.

❓ Troubleshoot

advanced

Diagnosing Cloud Build permission errors

You get this error when running a Cloud Build: "Permission denied: User does not have roles/cloudbuild.builds.editor." What is the most likely cause?

A The Dockerfile has syntax errors causing build failure.

B The user lacks the required IAM role to execute builds.

C The build config file is missing or malformed.

D The Cloud Build trigger is not linked to the correct GitHub repository.

💡 Hint

Focus on the permission error message and what controls build execution rights.

The error indicates the user running the build lacks the necessary IAM role to perform build operations.

✅ Best Practice

expert

Optimizing Cloud Build caching strategy

Which Cloud Build configuration best enables caching to speed up Docker image builds?

A

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '--cache-from', 'gcr.io/my-project/my-image:latest', '-t', 'gcr.io/my-project/my-image', '.']
options:
  machineType: 'E2_HIGHCPU_8'

B

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
options:
  logging: 'DEBUG'

C

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '--no-cache', '-t', 'gcr.io/my-project/my-image', '.']

D

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
substitutions:
  _CACHE: 'true'

💡 Hint

Look for Docker build options that enable cache reuse.

Using '--cache-from' with a previously built image allows Docker to reuse layers, speeding up builds. Other options do not enable caching or disable it.

Practice

1. What is the primary purpose of Google Cloud Build in a CI/CD pipeline?

easy

A. To store large amounts of data

B. To automate building, testing, and deploying code

C. To monitor network traffic

D. To manage user permissions

Solution

1. Step 1: Understand Cloud Build's role

   Cloud Build automates the process of building, testing, and deploying code, which is essential in CI/CD pipelines.

2. Step 2: Eliminate unrelated options

   Storing data, monitoring network traffic, and managing permissions are not primary functions of Cloud Build.

3. Final Answer:

   To automate building, testing, and deploying code -> Option B

4. Quick Check:

   Cloud Build = Automate build/test/deploy [OK]

Hint: Remember: Cloud Build automates code delivery steps [OK]

Common Mistakes:

• Confusing Cloud Build with storage services
• Thinking Cloud Build manages network or permissions
• Assuming Cloud Build only builds code without testing or deploying

2. Which of the following is the correct way to specify a build step in a Cloud Build YAML file?

easy

A. actions:
- image: 'docker'
run: ['build', '-t', 'image', '.']

B. build_steps:
- container: 'gcr.io/cloud-builders/docker'
commands: ['build', '-t', 'image', '.']

C. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']

D. commands:
- use: 'docker'
execute: ['build', '-t', 'image', '.']

Solution

1. Step 1: Review Cloud Build YAML syntax

   The correct key for build steps is 'steps', and each step uses 'name' for the builder image and 'args' for commands.

2. Step 2: Compare options to syntax

   steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] matches the correct syntax. Other options use incorrect keys like 'build_steps', 'actions', or 'commands'.

3. Final Answer:

   steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] -> Option C

4. Quick Check:

   Use 'steps' with 'name' and 'args' in Cloud Build YAML [OK]

Hint: Look for 'steps' with 'name' and 'args' keys in YAML [OK]

Common Mistakes:

• Using wrong keys like 'build_steps' or 'actions'
• Confusing 'args' with 'commands'
• Omitting the builder image name

3. Given this Cloud Build YAML snippet, what will be the output of the build step?

steps:
- name: 'ubuntu'
  args: ['echo', 'Hello, Cloud Build!']

medium

A. Build fails due to missing Docker image

B. Syntax error in YAML file

C. No output is produced

D. Hello, Cloud Build!

Solution

1. Step 1: Analyze the build step

   The step uses the 'ubuntu' image and runs the command 'echo Hello, Cloud Build!'. This command prints the message to the output.

2. Step 2: Determine expected output

   Since 'echo' prints text, the output will be 'Hello, Cloud Build!'. There is no syntax error or missing image because 'ubuntu' is a valid public image.

3. Final Answer:

   Hello, Cloud Build! -> Option D

4. Quick Check:

   Echo command prints text output [OK]

Hint: Echo commands print their arguments as output [OK]

Common Mistakes:

• Assuming build fails due to image name
• Thinking no output is produced by echo
• Confusing YAML syntax errors with valid syntax

4. You wrote this Cloud Build YAML but the build fails immediately. What is the error?

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project/my-image']

medium

A. Missing the build context (dot) at the end of args

B. Incorrect builder image name

C. YAML indentation error

D. args should be a string, not a list

Solution

1. Step 1: Check Docker build command syntax

   The Docker build command requires a build context, usually '.' at the end, to specify where to find the Dockerfile.

2. Step 2: Identify missing argument

   The args list misses the '.' context argument, causing the build to fail immediately.

3. Final Answer:

   Missing the build context (dot) at the end of args -> Option A

4. Quick Check:

   Docker build needs context path '.' [OK]

Hint: Always end docker build args with '.' for context [OK]

Common Mistakes:

• Assuming image name is wrong
• Thinking YAML indentation is the issue
• Using string instead of list for args

5. You want to create a Cloud Build pipeline that builds a Docker image, runs tests, and then deploys only if tests pass. Which YAML structure correctly represents this workflow?

hard

A. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
- name: 'gcr.io/cloud-builders/docker'
args: ['run', 'my-image', 'test']
waitFor: ['-']
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy']
waitFor: ['-']

B. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
waitFor: ['-']
- name: 'gcr.io/cloud-builders/docker'
args: ['run', 'my-image', 'test']
waitFor: ['-']
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy']

C. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
- name: 'gcr.io/cloud-builders/docker'
args: ['run', 'my-image', 'test']
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy']

D. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
- name: 'gcr.io/cloud-builders/docker'
args: ['run', 'my-image', 'test']
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy']
waitFor: ['-']

Solution

1. Step 1: Understand step dependencies in Cloud Build

   Cloud Build starts steps in parallel by default. Use 'waitFor: ["-"]' to make a step wait for all previous steps to succeed.

2. Step 2: Analyze options for correct workflow

   steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['run', 'my-image', 'test'] waitFor: ['-'] - name: 'gcr.io/cloud-builders/gcloud' args: ['app', 'deploy'] waitFor: ['-'] in steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['run', 'my-image', 'test'] waitFor: ['-'] - name: 'gcr.io/cloud-builders/gcloud' args: ['app', 'deploy'] waitFor: ['-'] ensures tests wait for build, and deploy waits for both.

3. Final Answer:

   steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['run', 'my-image', 'test'] waitFor: ['-'] - name: 'gcr.io/cloud-builders/gcloud' args: ['app', 'deploy'] waitFor: ['-'] -> Option A

4. Quick Check:

   waitFor ['-'] on test and deploy enforces build -> test -> deploy [OK]

Hint: Use waitFor: ['-'] on test and deploy steps for sequential workflow [OK]

Common Mistakes:

• Adding 'waitFor' incorrectly on all steps
• Omitting 'waitFor' causing deploy to run too early
• Misplacing 'waitFor' inside wrong steps