GH-600 · Domain 3: Manage memory, state, and execution · 12% of the exam
Task 3.2: Persist agent state and manage context drift
Recording progress and decisions as durable artifacts, resuming work without repeating or contradicting earlier steps, and catching drift in long runs.
Study it
Durable progress: plans, checkpoints, session state and resuming work
Try each one before opening the answer. Every option is explained, with the GitHub documentation page that proves it.
Question 1 · choose 1
A team builds a review bot on the Copilot SDK that must pick up a long task again after its process restarts on the same machine. In testing, every restart starts from nothing, although session state is written to disk. The code calls createSession without any ID. What is the fix?
AWrite the conversation to a JSON file and replay it into a new session
BPass a meaningful session ID, such as user-123-task-456, and resume it
CTurn on infinite sessions so the conversation is never lost
DStore the conversation in Copilot Memory, which the SDK reloads on startup
Show the answer and why
AWrite the conversation to a JSON file and replay it into a new session
Incorrect
The SDK persists state itself; what is missing is a known session ID to resume with.
BPass a meaningful session ID, such as user-123-task-456, and resume it
Correct
Without your own ID the SDK generates a random one, and the session can't be resumed later.
CTurn on infinite sessions so the conversation is never lost
Incorrect
Infinite sessions compact long conversations; they don't make a session resumable.
DStore the conversation in Copilot Memory, which the SDK reloads on startup
Incorrect
Copilot Memory stores repository facts and preferences, not SDK conversation state.
The key to resumable SDK sessions is providing your own session ID. Without one, the SDK generates a random ID and the session can't be resumed later. With an ID, conversation history, tool results, planning state and artifacts are persisted under ~/.copilot/session-state/, and resumeSession with the same ID continues the work, even from another client instance.
In an SDK chat app, a user sees the agent starting to rewrite a module the team agreed to leave alone, and types "Stop, keep the old module." The app sends the message with the default delivery mode, and the agent finishes the rewrite before reading it. What should the app use?
Amode: "enqueue", so the message runs as its own turn first
BA system-sourced message, which overrides whatever the agent is doing
Cmode: "immediate", which injects the message into the current turn
DCalling clearContext, then sending the correction as the seed prompt
Show the answer and why
Amode: "enqueue", so the message runs as its own turn first
Incorrect
Enqueue is the default and waits until the current turn finishes, which is what happened here.
BA system-sourced message, which overrides whatever the agent is doing
Incorrect
system provenance is for internal application context, not for user course corrections.
Cmode: "immediate", which injects the message into the current turn
Correct
Steering in immediate mode is injected into the current LLM turn, so the agent adjusts as it works.
DCalling clearContext, then sending the correction as the seed prompt
Incorrect
Clearing context wipes the conversation; it is a reset, not a correction mid-turn.
The SDK offers two ways to send messages while the agent works. Steering (mode "immediate") is injected into the current turn; if the agent has already committed to a tool call, it takes effect after that call but within the same turn. Queueing (mode "enqueue"), the default, processes the message as a new turn after the current one finishes.
A developer stops a Copilot CLI cloud sandbox session at the end of the day. What happens to its work?
AEverything is discarded, like a cloud agent job
BIts state is saved as a snapshot and restored when it is resumed
CThe files are pushed to a new branch
DThe session keeps running on GitHub's infrastructure until someone deletes it
Show the answer and why
AEverything is discarded, like a cloud agent job
Incorrect
A stopped cloud sandbox keeps a snapshot; only deletion removes it.
BIts state is saved as a snapshot and restored when it is resumed
Correct
Stopping creates a snapshot so files, variables and in-progress work come back on resume.
CThe files are pushed to a new branch
Incorrect
Stopping saves a snapshot; it doesn't push anything.
DThe session keeps running on GitHub's infrastructure until someone deletes it
Incorrect
A stopped session isn't running; its state is saved.
A cloud sandbox session is active, stopped or deleted. When you stop a session, the sandbox creates a snapshot of its state, and resuming restores your files, environment variables and in-progress work. Deleting removes both the running environment and the snapshot.
An SDK app finishes a task and wants to free memory but keep the option to resume the session next week. Which call fits?
Aclient.deleteSession(id)
Bsession.history.clearContext()
CNothing; idle sessions are cleaned up after 30 minutes by default
Dsession.disconnect()
Show the answer and why
Aclient.deleteSession(id)
Incorrect
deleteSession permanently removes the session and its files; it can't be resumed.
Bsession.history.clearContext()
Incorrect
clearContext replaces the conversation in a live session; it doesn't free the session.
CNothing; idle sessions are cleaned up after 30 minutes by default
Incorrect
By default sessions have no idle timeout.
Dsession.disconnect()
Correct
disconnect() releases in-memory resources and preserves the session data on disk.
When a task completes, call disconnect() rather than waiting for timeouts: it releases in-memory resources but keeps session data on disk, so the session can be resumed. deleteSession() permanently removes everything, including files. Sessions have no idle timeout unless you set sessionIdleTimeoutSeconds.
What kind of session ID does GitHub recommend for a multi-user app built on the Copilot SDK?
AA structured ID such as user-alice-pr-review-42
BA random ID such as abc123
CThe same ID for every user, to share context
DThe user's email address alone
Show the answer and why
AA structured ID such as user-alice-pr-review-42
Correct
IDs that encode ownership and purpose make auditing and cleanup easier.
BA random ID such as abc123
Incorrect
Random IDs are hard to audit and carry no ownership information.
CThe same ID for every user, to share context
Incorrect
Multi-user apps need unique IDs per user.
DThe user's email address alone
Incorrect
The recommended patterns combine owner and task, not just identity.
GitHub recommends session IDs that encode ownership and purpose, such as user-{userId}-{taskId}, tenant-{tenantId}-{workflow} or {userId}-{taskId}-{timestamp}. Structured IDs make it easy to audit sessions for a user, clean up old ones and enforce access control.
A developer had remote control enabled for a Copilot CLI session, closed it, and later runs copilot --resume to continue it. What happens to remote control?
AIt must be enabled again from scratch
BIt is replaced by a cloud sandbox session
CIt is turned back on automatically
DIt works only if the session was in Autopilot
Show the answer and why
AIt must be enabled again from scratch
Incorrect
It is re-enabled automatically on resume.
BIt is replaced by a cloud sandbox session
Incorrect
Resuming doesn't move the session to a cloud sandbox.
CIt is turned back on automatically
Correct
Resuming with --continue or --resume automatically re-enables remote control for that session.
DIt works only if the session was in Autopilot
Incorrect
Remote control doesn't depend on the session mode.
Remote control lets you monitor and steer a Copilot CLI session from GitHub.com or GitHub Mobile while it runs on your machine. When you resume a session that had remote control enabled, with copilot --continue or copilot --resume, remote control is re-enabled automatically.