GitHub Agentic AI Developer · 13% of the exam

Manage memory, state, and execution: free practice questions

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

1. An agent is designed to help users draft and iteratively refine long technical documents across multiple sessions. After the first session ends, the agent must remember the overall document structure and user-approved section headings, but does NOT need to retain the raw intermediate drafts the user rejected. Which memory strategy best fits this requirement?

  • A. Store the entire conversation history including all rejected drafts in short-term memory so the agent can reference the full context on next launch.
  • B. Persist only the approved document structure and section headings as long-term memory artifacts, discarding intermediate drafts after each session.✓ Correct
  • C. Use external vector storage to embed every message in the conversation and retrieve all of them at the start of the next session.
  • D. Rely on the model's in-context window across sessions by passing the full prior session transcript each time the user reconnects.
Explanation

Option B is correct because persisting only task-relevant, user-approved artifacts (document structure and headings) as long-term memory satisfies the requirement to remember decisions without retaining unnecessary rejected content — this is scoping agent memory to task-relevant information. Option A is wrong because storing all rejected drafts in short-term memory wastes context and violates the principle of scoping memory; short-term memory does not persist across sessions anyway. Option C is wrong because embedding every message — including rejected drafts — in an external store contradicts the goal of discarding non-relevant content and would cause stale, unwanted context to influence future decisions. Option D is wrong because re-injecting the full prior transcript each session bloats the context window and makes the agent process information the user explicitly rejected, risking context drift.

2. An agent is used by a development team to triage GitHub Issues. It maintains a working memory of the current issue batch in its context window. After processing 200 issues over three hours, stakeholders notice that the agent's triage decisions start to drift — it begins mis-classifying issue priorities in ways inconsistent with its earlier, correct decisions. What is MOST likely causing this behavior, and what is the recommended corrective action?

  • A. The agent's model weights have degraded; redeploy the model to restore original behavior.
  • B. The agent has accumulated context drift as the session lengthened, diluting or shifting the effective representation of its initial instructions; correct this by implementing periodic context refresh checkpoints that re-inject core instructions and re-validate the agent's decision baseline.✓ Correct
  • C. The GitHub Issues API is returning cached stale data; implement a cache-busting strategy on API calls to ensure fresh issue data.
  • D. The agent is running out of compute quota; scale up the underlying compute resources to stabilize decision quality.
Explanation

Option B 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 A 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 C 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 D is wrong because compute resource limits affect throughput and latency, not the logical consistency of the model's decisions.

3. A developer is building a multi-agent system in which two concurrent agent sessions — one triggered by a CI pipeline and one triggered by a developer's IDE chat — both read and write shared deployment configuration state. The team reports that the agents occasionally overwrite each other's configuration changes, causing deployment failures. Which TWO practices should the developer implement to prevent conflicting context between these concurrent sessions? (Choose TWO.)

  • A. Implement optimistic or pessimistic locking on the shared state store so that only one agent session can write deployment configuration at a time.✓ Correct
  • B. Assign each agent session a separate, isolated memory namespace and merge changes through a conflict-resolution layer before committing to shared state.✓ Correct
  • C. Increase the polling interval of both agents so they are less likely to run at the same time.
  • D. Store all deployment configuration in each agent's in-context short-term memory to eliminate shared state entirely.
  • E. Configure both agents to use the same system prompt so their decisions are aligned and conflicts are prevented automatically.
Explanation

Options A and B are correct. Option A (locking) is the classical concurrency control mechanism — preventing simultaneous writes to shared state eliminates the race condition directly. Option B (isolated namespaces with a conflict-resolution merge layer) is the modern agent-design pattern that lets each session operate independently and then reconciles changes safely before committing, directly addressing the 'preventing conflicting context between concurrent agent sessions' skill. Option C is wrong because increasing polling intervals only reduces collision probability and does not eliminate conflicts; under load, the race condition will still occur. Option D is wrong because putting shared deployment config in each agent's short-term in-context memory does NOT eliminate shared state — it duplicates it, making conflicts worse and losing cross-session visibility. Option E is wrong because a shared system prompt aligns intent but does nothing to coordinate writes to external state; both agents could make independent, well-intentioned but conflicting changes with identical system prompts.

4. A GitHub Copilot agent autonomously executes a multi-step code migration task that can take several hours. Midway through execution, the compute environment is recycled and the agent process is terminated. When a new agent instance starts, it must resume work from the point of interruption without repeating already-completed migration steps. What is the MOST effective approach to enable this behavior?

  • A. Re-run the entire migration from the beginning each time, relying on idempotent operations to avoid side effects.
  • B. Capture task progress and each completed migration step as durable artifacts (e.g., a persisted progress ledger) that the new agent instance reads on startup.✓ Correct
  • C. Increase the agent's in-context memory allocation so the model retains intermediate state even after the process restarts.
  • D. Configure the orchestrator to send a summary email of completed steps to the user, who then re-enters them manually when the agent resumes.
Explanation

Option B is correct because capturing task progress and decisions as durable, externally persisted artifacts (a progress ledger or checkpoint file) allows a new agent instance to read the ledger, determine what has already been completed, and resume from the correct point — directly addressing the 'capturing task progress as durable artifacts' and 'resuming without repeating steps' competencies. Option A is wrong because re-running from the start wastes time and can cause unintended side effects even with idempotency; it does not represent a resume strategy. Option C is wrong because in-context memory is volatile and does not survive process termination; there is no 'context allocation' that persists across restarts. Option D is wrong because requiring manual re-entry introduces human error, breaks automation, and is not a scalable or reliable pattern for agent continuity.

5. A team is designing a long-running agentic workflow that processes large GitHub repository audit logs. The agent must maintain awareness of findings across thousands of log entries without exceeding the model's context window limit. The solution must also ensure that findings from six months ago do not silently influence current audit decisions unless explicitly retrieved. Which combination of THREE design choices correctly addresses these constraints? (Choose THREE.)

  • A. Store all historical findings in an external semantic search index; retrieve only the findings relevant to the current log entry via similarity search at each step.✓ Correct
  • B. Use a rolling window that keeps only the last N log entries in the active context, discarding older entries from the window as new ones arrive.
  • C. Summarize completed audit batches into compressed, structured durable artifacts and archive them outside the active context, making them available on explicit retrieval only.✓ Correct
  • D. Expand the model's context window by upgrading to a model with a larger token limit so all findings fit in memory simultaneously.
  • E. Set a staleness threshold on archived findings so that findings older than a defined period are flagged as potentially stale and require explicit agent confirmation before influencing a decision.✓ Correct
  • F. Replicate the full context window state to every tool integration endpoint so all tools always have complete historical context.
Explanation

Options A, C, and E are correct. Option A (external semantic search with on-demand retrieval) addresses the context window constraint by keeping historical data outside active context and pulling only relevant information — this is the 'external memory' pattern that prevents context overflow. Option C (compressing completed batches into durable archived artifacts) directly maps to 'capturing task progress and decisions as durable artifacts' and ensures older findings do not passively linger in context. Option E (staleness thresholds requiring explicit confirmation) directly addresses 'preventing stale context from influencing agent decisions' — findings older than the threshold are not ignored but must be deliberately retrieved and confirmed, giving the agent control over historical influence. Option B is wrong because a simple rolling window discards older findings entirely rather than archiving them — this causes loss of important audit history that may need to be retrieved deliberately. Option D is wrong because upgrading to a larger context model does not solve the architectural problem of stale context influence; even with a larger window, six-month-old findings would silently affect decisions. Option F is wrong because replicating the full context to all tool endpoints introduces massive redundancy, amplifies stale context problems across every integration, and contradicts the principle of scoping context to task-relevant information.

3 more questions in this domain

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

Start practicing free