Free GH-600 practice test

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.

Emitting structured trace files (such as OpenTelemetry-formatted spans) as GitHub Actions artifacts meets all requirements: traces are tied to a specific run, stored in standard dev tooling, accessible without runtime access, and retained per compliance policy. Container logs are ephemeral and not surfaced as standard artifacts in dev tooling. Relying on the LLM provider's internal logs introduces a third-party dependency and doesn't store traces in the team's own standard tooling. Relying on a system prompt for auditability is not a real control — LLMs don't inherently produce auditable structured traces.

Passing existing unit tests, maintaining or reducing cyclomatic complexity, introducing no new linting errors, and producing a structured diff artifact are all objectively measurable, automated, and directly tied to refactoring quality — ideal success criteria. 'Do its best' with subjective review is not a measurable criterion and defeats the purpose of defining success criteria. Lines of code produced is a vanity metric that incentivizes verbosity over quality. Sentiment ratings are subjective, non-automatable, and not aligned with engineering quality outcomes.

JSON or YAML with a defined schema is both human-readable (reviewers can inspect it directly in a PR comment or file) and machine-parseable (validation tooling can deserialize and validate it against the schema). Free-form natural language is human-readable but difficult for automated tooling to parse reliably. Binary Protocol Buffers are highly machine-efficient but not human-readable without special tooling. A compiled executable is neither human-readable nor a structured data plan — it encodes behavior, not a declarative plan artifact.

GitHub Actions supports branch filtering on pull_request events using the branches key, which filters on the base (target) branch of the PR. Setting branches: [main] ensures the workflow—and therefore the agent—only runs when the PR is targeting main. Option B is incorrect because branch protection rules govern merge requirements, not which workflows are triggered; you cannot use them to selectively suppress a workflow invocation. Option A is incorrect because changing to a push trigger on main would invoke the agent after a merge, not during the PR review phase, which changes the intended behavior. Option D is incorrect because repository rulesets enforce policies (e.g., required checks, who can push) but do not selectively suppress specific workflow triggers based on PR target branch.

Opening a GitHub issue with full failure context and assigning it to the on-call team creates a durable, trackable escalation artifact that ensures no work is silently lost. This is the standard escalation path pattern for agentic systems. Option C is incorrect because exiting with a zero status code falsely signals success, hiding the failure from monitoring systems; this is the opposite of a documented escalation path. Option D is incorrect because indefinite retries can cause runaway resource consumption and hung workflows; there must be a terminal failure state with an escalation action. Option B is incorrect because continue-on-error: true suppresses failure signals in the workflow, and a weekly digest is not a timely escalation mechanism.

The GitHub remote MCP server is a GitHub-hosted endpoint that exposes GitHub platform capabilities (repositories, issues, PRs, etc.) as MCP tools, so developers do not need to run or maintain their own server infrastructure. Option A is incorrect because the remote MCP server is not tied to devcontainers or Codespaces; it is a cloud-hosted service. Option C is incorrect because authentication (OAuth tokens or GitHub App credentials) is still required; the remote MCP server does not eliminate authentication. Option D is incorrect because MCP tool outputs are returned to the agent at runtime and are not stored in GitHub Packages.

Scoping the agent to a specific repository in its configuration directly constrains the agent's execution context so it cannot act on repositories outside the intended scope. This is the precise control mechanism designed for this scenario. Option B is incorrect because removing contents: write prevents branch creation in the current repository but does not prevent the agent from operating against other repositories if it has other credentials or tokens. Option D is incorrect because changing the trigger to workflow_dispatch only affects when the workflow runs, not the scope of the agent's actions when it does run. Option C is incorrect because branch protection rules govern merge requirements and do not prevent an agent from creating branches or PRs in out-of-scope repositories.

Publishing a server to an MCP registry makes it available for adoption, but each repository must still opt in by adding the server to its MCP allow list. This two-step model (registry publication + per-repository allow listing) ensures that tool access is deliberate and scoped. Option A is incorrect because forking the registry does not affect the agent's configuration in the original repository; the allow list in the actual repository must be updated. Option C is incorrect because MCP server activation is self-service via configuration, not a GitHub Support process. Option D is incorrect because MCP server registration is a one-time configuration change, not a workflow step that must run on every execution.

Option D is correct because extended agent execution causes context drift — as more content accumulates in the context window, earlier instructions and decision criteria can become diluted or misrepresented. The recommended practice is to detect this drift pattern and apply periodic context refresh checkpoints that re-inject authoritative instructions and validate the agent's reasoning baseline, directly mapping to the 'detecting and correcting context drift during extended agent execution' skill. Option C is wrong because model weights do not degrade at runtime; model behavior within a session is deterministic given the same context — the problem is context content, not model integrity. Option B is wrong because stale API data would cause incorrect issue content, not drift in prioritization logic; the symptom described is about decision consistency, not data freshness. Option A is wrong because compute resource limits affect throughput and latency, not the logical consistency of the model's decisions.

Option B is correct because tying memory expiration to the lifecycle of the associated artifact (the vulnerability ticket) rather than an arbitrary wall-clock interval is the principled approach to defining memory expiration rules. A ticket that is reopened is still active and its prior decisions remain relevant — the expiration should only trigger when the ticket is closed and confirmed resolved for a sufficient period. This directly addresses the 'defining memory expiration, pruning, and reset rules' skill. Option A is wrong because never-expiring memory causes unbounded growth and will eventually include stale, irrelevant decisions that pollute the agent's context — the goal is lifecycle-aware expiration, not no expiration. Option C is wrong because changing 24 hours to 72 hours is an arbitrary adjustment that does not fix the underlying design flaw; a ticket reopened after a week would still lose its history. Option D is wrong because requiring manual import is a labor-intensive workaround that undermines the automation benefits of agent memory systems and does not constitute a proper memory management rule.

Option B is correct because the root cause is an incomplete memory reset — the team reset one memory layer (likely the agent's long-term memory store) but an external state cache was not included in the reset scope. The 10 repositories read from this forgotten cache and received stale, pre-policy-update configuration. The architectural fix is a unified memory topology map: a documented, enforced catalog of every storage layer so that reset, pruning, and expiration operations are applied atomically across all layers simultaneously. This directly addresses the 'defining memory expiration, pruning, and reset rules' and 'preventing stale context from influencing agent decisions' skills. Option D is wrong because the speed of the reset is irrelevant — the problem is incompleteness (a missed store), not latency. Option C is wrong because the scenario states the agent correctly updated 40 repositories, which means it had sufficient permissions; permission is not the differentiating factor for the 10 failures. Option A is wrong because configuration heterogeneity across repositories is normal and expected; the failure is purely about stale cached state being applied, not about policy inconsistency.

Evaluation signals from automated scanners are used to identify gaps between agent behavior and desired behavior, and the appropriate response is to tune the agent — most directly by revising instructions or adding constraints (e.g., 'never include credentials in output files'). Option B (retraining the model) is outside the scope of agent-level tuning and is not a standard GitHub Copilot workflow. Option A (revoking the token) is a security incident response, not an evaluation-driven tuning action. Option C (storing the bad output in memory) would propagate the undesired behavior rather than prevent it.

The trace clearly shows the agent called write_file with a 0-byte payload — it invoked the correct tool but provided incorrect (empty) content. This is tool misuse: the tool was used incorrectly (wrong argument), resulting in data loss. Option D is wrong because the write succeeded (the file is now empty, not unchanged). Option A (reasoning error) could be a secondary issue but does not describe the proximate cause visible in the trace. Option C (memory issue) is speculative and not supported by the trace evidence, which shows the agent did execute a write call.

An operational constraint is a boundary or rule the agent must observe during task execution — for example, 'never push directly to the main branch' or 'only read files within the repository scope.' It governs how the agent behaves, independent of whether it achieves the goal. Option A describes a success metric or threshold, not a constraint. Option C describes a logging artifact. Option D describes a system prompt component, which may contain constraints but is not itself the definition of an operational constraint.

Correct: A human-in-the-loop (HITL) recovery step is a deliberate pause mechanism: it surfaces agent state and failure context to a human operator, who then makes an informed decision to resume, modify, or redirect the workflow. It preserves human oversight at critical recovery decision points without permanently replacing automation. — Wrong (A): Automatic retry with modified parameters is an automated recovery strategy (e.g., retry-with-backoff or parameter perturbation), not a human-in-the-loop pattern; HITL specifically requires human involvement. — Wrong (C): HITL does not permanently replace downstream automation; it is a conditional intervention at a specific decision point, after which automated agents typically resume. — Wrong (D): Automatic rollback to a checkpoint is a distinct recovery pattern (rollback recovery); HITL specifically defers the recovery decision to a human rather than executing it automatically.

Correct: Signed structured decision records appended at each handoff directly satisfy all three CAB requirements: agent identity addresses (1), decision criteria addresses (2), and the upstream agent reference chain addresses (3). An immutable store prevents post-hoc tampering, and the summary report makes the evidence accessible to reviewers. — Wrong (A): Verbose logging produces unstructured, high-volume output that does not map cleanly to the three specific CAB evidence requirements; it requires manual correlation across log lines and does not provide attributable agent-level decision records. — Wrong (C): A GitHub Release captures the end state but contains no per-agent decision attribution or handoff sequence, omitting requirements (1) and (3). — Wrong (D): Human approval logs address human-in-the-loop checkpoints but do not capture autonomous agent decision criteria or the inter-agent handoff sequence; they partially address (1) only for human approvers, not agents.

Correct: In a hierarchical orchestration pattern, the coordinator agent's role is planning and synthesis — it breaks a complex goal into sub-tasks, assigns them to specialized subordinate agents, and integrates their individual outputs into a unified outcome. This is the defining characteristic of the orchestrator/coordinator role. — Wrong (D): Direct domain-specific task execution describes a worker or specialist agent, not a coordinator; coordinators delegate rather than execute domain tasks. — Wrong (C): Automated health monitoring and restart logic describes a watchdog or supervisor component, which is a distinct infrastructure concern from orchestration coordination. — Wrong (B): API proxying for rate-limit management is an infrastructure cross-cutting concern, not an orchestration pattern role; conflating it with coordination reflects a common architectural misunderstanding.

Differentiating the approval path by risk classification—fully automated for low/moderate, human-gated for critical on direct production dependencies—is the canonical 'autonomy level' design pattern described in the domain. It preserves velocity for the majority of alerts while applying the human-in-the-loop control exactly where risk justifies it. Option B (post-merge Slack notification) provides no pre-merge control; a merged critical vulnerability is already in the codebase before a human can act. Option D (pausing the whole pipeline for any critical alert) is disproportionately disruptive and slows remediation of low-risk alerts unnecessarily. Option A (all PRs human-reviewed) eliminates the velocity benefit of automation and adds approvals that do not materially reduce risk for low-severity updates.

Option E (URL allowlisting) is a direct output guardrail: even if the agent is tricked into calling the webhook API, only pre-approved domains can be registered, neutralizing data exfiltration. Option C (human approval for user-input-triggered webhook changes) applies the human-in-the-loop control precisely to the high-risk, compliance-sensitive action class, blocking the attack path before it reaches the API. Option F (prompt-injection guard) addresses the root cause—the attacker's ability to hijack the agent's decision-making via crafted input—by intercepting malicious instructions before the agent acts on them. Option D (narrowing installation scope) is a good least-privilege practice but does not prevent the attack within the permitted repositories; it only limits blast radius. Option A is wrong and counterproductive: a longer-lived token increases risk, not security, and is unrelated to the webhook injection vector. Option B (archiving repositories) is a disproportionate, disruptive response that harms legitimate users and does not systematically prevent the attack class.