AZ-400 Practice Question: Design and implement a source control strategy
Your development team uses GitHub for source control. You want to automatically run a set of tests every time a pull request is opened against the main branch. What should you configure?
⚠ Common exam trap
Test-takers frequently confuse branch protection rules (which enforce status checks) with the actual mechanism that triggers the tests, leading them to select Option D, but protection rules only block merges without initiating any automated testing.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Create a GitHub Actions workflow triggered by pull_request events to main
GitHub Actions natively supports the `pull_request` event trigger, which can be configured to run workflows automatically when a pull request is opened against a specific branch (e.g., `main`). This allows you to define a YAML-based workflow in the `.github/workflows` directory that executes tests on every PR event, providing immediate feedback to developers without requiring external services or manual API calls.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create a GitHub Actions workflow triggered by pull_request events to main
Why this is correct
A GitHub Actions workflow with a `pull_request` trigger to `main` is the native, built-in CI/CD solution: it automatically runs any defined test jobs on every PR, and its resulting status checks integrate directly with GitHub’s branch protection and PR UI. This is the correct approach because no external service or custom listener is needed.
- ✗
Use the GitHub API to trigger tests when a PR is opened
Why it's wrong here
Using the GitHub API to trigger tests when a PR is opened requires a custom service or listener that polls or receives events, then makes API calls to invoke external test jobs; GitHub itself does not run tests from API calls alone. This adds unnecessary infrastructure and complexity compared to a native workflow.
- ✗
Set up a webhook to trigger an external CI system
Why it's wrong here
Setting up a webhook to trigger an external CI system requires separate hosting, configuration, and maintenance of that CI service plus a public endpoint to receive the webhook payload; unlike GitHub Actions, this is not built into the GitHub platform and introduces an extra failure point and operational overhead.
- ✗
Configure a branch protection rule to require status checks
Why it's wrong here
A branch protection rule that requires status checks can enforce that checks pass before merging, but it does not create or run any tests itself—it merely blocks merges unless a reported check succeeds. You still need an actual CI system like GitHub Actions to produce and report that required status check.
Go deeper
Related to this question
Learn chapter
Implementing and Managing Source Control
Key term
Pull request
A pull request is a way for a developer to propose changes to a codebase and ask other team members to review and merge them into the main project.
Key term
GitHub
GitHub is a cloud-based platform for storing, tracking, and collaborating on code using Git version control.
About these practice questions
This AZ-400 question is part of Courseiva's 696-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.