GitHub Agentic AI Developer · 18% of the exam

Prepare agent architecture and SDLC processes: free practice questions

5 sample questions from our 11-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real GitHub exam.

1. A development team is integrating a GitHub Copilot agent into their SDLC. They want the agent to assist during the requirements phase. Which task is MOST appropriate for the agent to perform at this stage?

  • A. Decompose user stories into discrete, verifiable acceptance criteria and flag ambiguous requirements for human review✓ Correct
  • B. Automatically merge pull requests that pass all CI checks without human approval
  • C. Deploy the application to the staging environment after requirements are finalized
  • D. Generate unit tests and execute them against the production codebase
Explanation

During the requirements phase, an agent's appropriate role is to help structure and clarify inputs — such as decomposing user stories into acceptance criteria and surfacing ambiguities for human review — which aligns with defining inputs and success criteria. Automatically merging pull requests is an action phase activity that bypasses human oversight. Deploying to staging belongs to the release/delivery phase. Generating and running unit tests against production is inappropriate at the requirements phase and introduces unacceptable risk.

2. A team is implementing a multi-stage agentic pipeline in GitHub Actions. The pipeline includes: (1) a planning stage where the agent outputs a structured change plan, (2) a validation stage where automated checks verify the plan against policy rules, and (3) an execution stage where the agent applies changes. After a recent incident, the team wants to ensure human intervention is possible between validation and execution WITHOUT introducing a mandatory synchronous approval that blocks the pipeline for hours. Which THREE design choices support this goal?

  • A. Set a configurable auto-approval timeout (e.g., 30 minutes) so the pipeline proceeds automatically if no reviewer objects, while still notifying the on-call engineer via GitHub notification✓ Correct
  • B. Require a synchronous manual approval with no timeout, forcing a reviewer to be available 24/7
  • C. Post the validated plan as a PR comment and allow reviewers to post a '/reject' command that triggers a workflow cancellation webhook before the timeout expires✓ Correct
  • D. Persist the validated plan artifact to a GitHub Release so it can be referenced asynchronously by reviewers on their own schedule
  • E. Implement a 'dead man's switch' pattern where the execution stage is blocked by default and only proceeds after a reviewer explicitly posts '/approve' within the timeout window✓ Correct
  • F. Skip the validation stage entirely and rely solely on post-execution rollback scripts to handle errors
Explanation

A configurable auto-approval timeout with on-call notification enables human intervention without indefinitely blocking the pipeline — reviewers can act quickly when needed, and delivery proceeds automatically when no issues are flagged. A '/reject' command mechanism gives reviewers an active, low-friction way to halt execution asynchronously without requiring synchronous presence. A 'dead man's switch' (explicit '/approve' required within a window) is another valid pattern that defaults to safe blocking but doesn't require 24/7 coverage if the window is reasonable. A mandatory synchronous approval with no timeout directly contradicts the requirement not to block delivery for hours. Persisting the plan to a GitHub Release is useful for archiving but does not by itself provide an intervention mechanism. Skipping validation eliminates a critical safety gate and is directly contrary to the goal.

3. A team configures a GitHub Actions workflow so that their agentic coding assistant produces a structured YAML plan file — listing every file to be modified, every shell command to be run, and every API to be called — before any execution step begins. The workflow then pauses for a required human approval on that plan artifact. Which TWO primary benefits does this architecture provide?

  • A. It eliminates the need for automated testing because the plan serves as a test suite
  • B. It creates an inspectable artifact that allows reviewers to assess agent intent before side effects occur✓ Correct
  • C. It enforces a clear boundary between agent planning and agent execution✓ Correct
  • D. It guarantees the agent will never produce an incorrect plan
  • E. It reduces token usage by caching the plan across multiple agent runs
  • F. It allows the agent to autonomously approve its own plan when no reviewer is available
Explanation

Producing a structured plan artifact before execution creates an inspectable record of what the agent intends to do, enabling human reviewers to assess risk before any side effects occur. It also enforces the architectural boundary between planning (reasoning) and execution (action), a core SDLC integration principle. It does not eliminate the need for testing — plans can be incorrect or incomplete. It does not guarantee plan correctness; human review is required precisely because plans can be wrong. Token caching is unrelated to this workflow design. Allowing the agent to self-approve defeats the purpose of the approval gate.

4. An organization wants to deploy an agent that can autonomously open and merge pull requests, but leadership requires that no code reaches the main branch without a human having reviewed the agent's intended changes. Which configuration BEST satisfies both autonomy and oversight requirements?

  • A. Configure the agent to commit directly to main after passing all CI checks, and send a retrospective notification email
  • B. Require the agent to open a pull request with a machine-readable plan comment, enforce a required reviewer approval rule on the branch protection policy, and block auto-merge until approval is granted✓ Correct
  • C. Disable branch protection rules so the agent can operate without interruption, then audit logs weekly
  • D. Allow the agent to merge immediately if confidence score exceeds 95%, bypassing review for high-confidence changes
Explanation

Requiring the agent to open a PR with a machine-readable plan, enforced by branch protection required-reviewer rules and blocked auto-merge, gives the agent autonomy to prepare changes while guaranteeing a human approval gate before merge — the correct balance. Committing directly to main with a retrospective notification provides no pre-merge oversight. Disabling branch protection eliminates the control plane entirely and weekly log audits are reactive, not preventive. A confidence-score bypass is a common misconception; model confidence is not a reliable proxy for correctness or safety and bypasses the oversight requirement.

5. An engineering manager reviews an agentic coding assistant's behavior and notices the agent often produces a plan, then silently revises the plan mid-execution when it encounters unexpected tool outputs, without surfacing the revision to reviewers. Which TWO risks does this behavior introduce?

  • A. The approved plan no longer reflects the actions actually taken, invalidating the audit trail✓ Correct
  • B. The agent will consume more GitHub Actions runner minutes than budgeted
  • C. Humans who approved the original plan have implicitly approved actions they never reviewed, creating a compliance gap✓ Correct
  • D. The agent's context window will be exhausted more quickly due to mid-execution replanning
  • E. The CI pipeline will automatically fail because GitHub detects plan divergence
Explanation

If the agent silently revises its plan mid-execution, the approved plan artifact no longer matches what was actually done, breaking the audit trail and making traceability impossible. Additionally, humans approved a plan that described different actions than were executed — they have implicitly 'approved' unapproved actions, creating a compliance and governance gap. Runner minute overuse is a cost concern unrelated to plan divergence. Context window exhaustion is a technical performance concern, not a governance risk introduced by silent replanning. GitHub Actions has no native mechanism to detect plan divergence automatically — that assertion is a misconception.

6 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free