Automating Integration Tests with Cloud Build and GitHub

PCDOE By islever Editorial Last updated

Implementing and managing pipelines.

Short answer

D Use Cloud Build to run tests in a specific folder and trigger Cloud Build for every GitHub pull request.

Question

You are developing reusable infrastructure as code modules. Each module contains integration tests that launch the module in a test project. You are using GitHub for source control. You need to continuously test your feature branch and ensure that all code is tested before changes are accepted. You need to implement a solution to automate the integration tests. What should you do?
  1. Use a Jenkins server for CI/CD pipelines. Periodically run all tests in the feature branch.
  2. Ask the pull request reviewers to run the integration tests before approving the code.
  3. Use Cloud Build to run the tests. Trigger all tests to run after a pull request is merged.
  4. Use Cloud Build to run tests in a specific folder. Trigger Cloud Build for every GitHub pull request. Correct Answer

Key Takeaways

The exam tests your understanding of CI/CD workflow timing, specifically the trap of triggering tests after a merge (which defeats the purpose of gating) versus triggering them before acceptance.

This question examines the correct configuration for integrating Google Cloud Build with GitHub to automate testing on feature branches. It establishes that triggering builds on pull request creation is essential for pre-merge validation.

Common mistake: Many candidates choose option C because it uses Cloud Build, but they overlook the critical timing detail: triggering 'after a pull request is merged' allows untested code to enter the main branch.

Expert Analysis

Why the Answer Is Correct

Option D is the correct answer because it leverages Cloud Build triggers configured for GitHub pull requests. This setup automatically executes integration tests as soon as a PR is created or updated, ensuring that all code changes are validated before they are accepted into the main branch. This aligns with the requirement to ensure all code is tested before changes are accepted.

Why the Other Options Are Wrong

Option A suggests using Jenkins, which adds unnecessary complexity when native GCP tools like Cloud Build are available and integrate directly with GitHub. Option B relies on manual human intervention, which contradicts the goal of automation. Option C is incorrect because triggering tests 'after a pull request is merged' means the code enters production/main without prior automated validation, violating the safety gate principle.

Community Comment Notes

The community consensus strongly favors D. As user Jay09812 noted, "Wouldnt it be D considering you would want to run the tests when the PR is created and not after the code is already merged." Another commenter highlighted that C is too late: "C is incorrect: Triggering tests after a pull request is merged is too late." This reinforces the importance of pre-merge checks in CI/CD pipelines.

Exam Strategy

Always look for keywords like 'automate', 'before changes are accepted', and 'continuous test'. These imply a pre-merge gate. Choose the option that triggers the pipeline on the event that happens before the final state change (e.g., Pull Request created/updated), not after (e.g., Merge completed).

Frequently Asked Questions

Why is option C wrong if it uses Cloud Build?

Option C triggers tests after the merge. The requirement is to test BEFORE changes are accepted, meaning the gate must happen at the PR stage, not post-merge.

Do I need a specific folder path in Cloud Build?

While the option mentions a specific folder, the key differentiator is the trigger mechanism (PR vs Merge). Cloud Build can be configured to watch specific directories within a repo for efficiency.

More PCDOE FAQ →

Discussion 11 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 11

  1. Jay09812 👍 3
    Wouldnt it be D considering you would want to run the tests when the PR is created and not after the code is already merged
  2. xhilmi 👍 2 Answered D
    Choose option D Use Cloud Build to run tests in a specific folder and trigger Cloud Build for every GitHub pull request. By configuring Cloud Build to run tests in a specific folder, you can focus on the relevant tests for the modified code in the feature branch. Triggering Cloud Build for every GitHub pull request ensures that tests are automatically executed whenever changes are proposed, providing continuous integration. This approach allows for automated testing of each pull request, providing early feedback to developers and ensuring that changes are thoroughly tested before being merged, contributing to a more reliable and efficient development process.
  3. mshafa 👍 2 Answered D
    This approach automates the testing process, integrates well with your existing tools (GitHub and GCP), and ensures that code is tested in the most relevant part of the development lifecycle - before merging into the main branch.
  4. activist 👍 2
    Answer C is correct. https://cloud.google.com/build/docs/automating-builds/create-manage-triggers
  5. pharao89 👍 2 Answered D
    D is what I do at work for this scenario and it works well.
Show 6 more comments
  1. koo_kai 👍 2 Answered D
    all code is tested before changes are accepted
  2. Jason_Cloud_at 👍 2 Answered C
    I would go with C
  3. BlackCoffee 👍 1 Answered D
    C is incorrect: Triggering tests after a pull request is merged is too late. The goal of integration testing in a feature branch workflow is to catch issues and gate the code before it is accepted into the main branch.
  4. lelele2023 👍 1 Answered D
    shouldn't be C since it makes the test to happen after merge. Answer is D - as soon as a PR gets created then it runs tests.
  5. 6a8c7ad 👍 1 Answered C
    D mentions folder. Huh? I’ll take C
  6. Jason_Cloud_at 👍 1
    Agreed

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Binary Authorization Attestor Implementation

S-grade

GKE Cluster and Namespace Design for Data Isolation

S-grade

Granting Log Export Permissions in Google Cloud

S-grade

Optimizing SLO Balance Between Reliability and Velocity

S-grade

Practice All PCDOE Questions

Access 75 questions with complete answers and detailed explanations.

View Full PCDOE Practice Test →

← Back to PCDOE Study Guide