Try each one before opening the answer. Every option is explained, with the GitHub documentation page that proves it.
Question 1 · choose 1
An SDK app shows the parent agent's response and each sub-agent's trace in separate panels. Events from all of them arrive on the same session stream. How should the renderer tell them apart?
ABy subscribing to a separate stream that the SDK opens for each sub-agent
BBy the order of events, since sub-agent events always come after the parent's
CBy the agentId on each event's envelope, which main-agent events don't carry
DBy the tools field of each event, which only sub-agents include
Show the answer and why
ABy subscribing to a separate stream that the SDK opens for each sub-agent
Incorrect
Sub-agent events share the parent session stream.
BBy the order of events, since sub-agent events always come after the parent's
Incorrect
Events interleave on one stream; the agentId marks which agent they belong to.
CBy the agentId on each event's envelope, which main-agent events don't carry
Correct
Sub-agent events include an envelope-level agentId; root agent and session-level events omit it.
DBy the tools field of each event, which only sub-agents include
Incorrect
tools appears on subagent.selected; the documented separator for all events is agentId.
When a sub-agent runs, the parent session emits lifecycle events such as subagent.started and subagent.completed. Sub-agent-originated session events share the parent session stream and include an envelope-level agentId, while root agent events and session-level events omit it, so renderers can keep the parent response separate from sub-agent traces.
After a fleet run, reviewers can't tell which sub-agent changed what or whether anything was tested, which makes the merged result hard to audit. Which practice from GitHub's fleet guidance addresses this?
ARun every worker as a single background sub-agent so its log stays separate
BHave every worker report what it changed, how it validated it and what is still blocked
CLet workers share one todo so they see each other's progress
DSkip the parent's final review, since each worker validated its own slice
Show the answer and why
ARun every worker as a single background sub-agent so its log stays separate
Incorrect
Separate logs don't say what each worker changed or tested; the workers' own reports are what make the work auditable.
BHave every worker report what it changed, how it validated it and what is still blocked
Correct
GitHub's best practices ask each worker to report changes, validation and remaining blockers.
CLet workers share one todo so they see each other's progress
Incorrect
Sharing a todo blurs ownership; auditability comes from each worker's report.
DSkip the parent's final review, since each worker validated its own slice
Incorrect
Dropping a review step makes the result harder to audit, not easier; the problem is the missing worker reports.
GitHub's fleet best practices include decomposing work into independent units, giving each todo a durable ID and complete description, and requiring every worker to report what it changed, how it validated the change and what remains blocked.
A team's dynamic workflow coordinates several subagents, and they want its progress shown in a custom view in the GitHub Copilot app, alongside the app's own list of runs. Where can such a view come from?
AA workflow run page in the repository's Actions tab
BA canvas provided by the workflow's extension
CA stream of the enterprise audit log
DThe repository's Copilot Memory page
Show the answer and why
AA workflow run page in the repository's Actions tab
Incorrect
Dynamic workflows run in Copilot clients, not as GitHub Actions workflow runs.
BA canvas provided by the workflow's extension
Correct
An extension can provide its own progress view, for example in a canvas in the Copilot app.
CA stream of the enterprise audit log
Incorrect
Audit log streaming is for enterprise auditing, not a progress view for a workflow run.
DThe repository's Copilot Memory page
Incorrect
Memory holds repository facts and user preferences, not workflow progress.
Dynamic workflows are defined in Copilot extensions. Besides the app's own view of current and past runs, an extension can provide its own progress view, for example in a canvas, a custom interface in the GitHub Copilot app that can also offer controls to start the workflow.
What can a subagentStart hook do when a sub-agent is about to run?
APrepend additionalContext to the sub-agent's prompt
BBlock the sub-agent from being created
CReplace the sub-agent's model
DApprove tool calls for the sub-agent
Show the answer and why
APrepend additionalContext to the sub-agent's prompt
Correct
subagentStart can't block creation, but additionalContext is prepended to the sub-agent's prompt.
BBlock the sub-agent from being created
Incorrect
subagentStart cannot block creation.
CReplace the sub-agent's model
Incorrect
The hook adds context; it doesn't pick the model.
DApprove tool calls for the sub-agent
Incorrect
Tool decisions belong to preToolUse.
subagentStart fires when a sub-agent is spawned, before it runs, and supports a matcher on the agent name. Its output is optional: it cannot block creation, but additionalContext is prepended to the sub-agent's prompt, which is useful for passing shared conventions or handoff notes.
In an enterprise audit log event for an agent action, which field identifies the person who initiated it?
Aactor
Bactor_is_agent
Cuser
Daction
Show the answer and why
Aactor
Incorrect
For agentic events the actor is Copilot; the initiator is in user.
Bactor_is_agent
Incorrect
That flag marks the actor as an agent.
Cuser
Correct
The user field is the person who initiated the agentic event.
Daction
Incorrect
action names what was done, such as pull_request.create.
In agentic audit log events, action names what the agent did, for example pull_request.create; actor_is_agent is always true; and user is the person who initiated the agentic event.
When Copilot CLI consults the rubber duck agent during a task, how does the critique appear in the session?
AAs the full critique pasted verbatim into the session output, line by line
BAs a separate pull request comment
CNot at all; it stays hidden
DAs a short summary of the critique and how Copilot responded
Show the answer and why
AAs the full critique pasted verbatim into the session output, line by line
Incorrect
It is summarized, not repeated word for word.
BAs a separate pull request comment
Incorrect
The summary appears in the session output.
CNot at all; it stays hidden
Incorrect
Copilot reports a summary in the session output.
DAs a short summary of the critique and how Copilot responded
Correct
Copilot summarizes the critique in the session output rather than repeating it verbatim.
When Copilot consults the rubber duck agent, it summarizes the resulting critique in the session output rather than repeating it verbatim, for example noting that the critique found a blind spot in its plan and that it updated the plan.