8 of the 15 questions in this set, with the correct answer marked and every option explained.
1. An enterprise is deploying an agent with write access to a customer records system. Which control provides the strongest assurance that an unintended write can be identified and reversed?
✓An immutable audit trail recording every action with its inputs, plus a reversible write path such as soft deletes or versioned records.
Assurance requires both halves: the audit trail answers what happened and why, and reversibility means the answer is actionable rather than merely informative. Either alone leaves you able to explain the damage but not undo it, or to undo something you cannot identify.
✗A carefully written system prompt instructing the agent to be careful with writes.
Prompt guidance shifts probabilities but provides no assurance and no recovery path. Governance controls must not depend on model compliance.
✗Restricting the agent to a single model provider.
Provider choice is a procurement and reliability decision. It says nothing about detecting or reversing an unintended write.
✗Running the agent in a container.
Containerization isolates the process from the host. It does nothing about writes the agent makes through its legitimate credentials to the records system.
2. A regulated client asks how the organization will demonstrate that its AI system behaves consistently over time. What is the most defensible answer?
✓A versioned evaluation suite run against every change to model, prompt or tooling, with results retained so behaviour can be compared across releases.
Consistency is a claim about behaviour over time, so it needs evidence over time. Versioned evaluations with retained results turn that claim into something auditable rather than asserted.
✗A statement that the model provider guarantees deterministic output.
No such guarantee exists, and repeating it to a regulated client would be a claim you cannot substantiate.
✗A commitment never to change the prompt after go-live.
Unrealistic and undesirable — prompts must evolve as requirements and models change. Freezing them replaces governance with paralysis.
✗Manual review of a handful of outputs each quarter by the delivery team.
Too sparse and too subjective to demonstrate consistency, and reviewing your own work quarterly is weak evidence for a regulator.
3. An executive sponsor asks for a single accuracy percentage to decide whether an agent is ready for production. How should the architect respond?
✓Explain that a single number hides the distribution of failures, and propose reporting performance broken down by task type alongside the consequence of each failure mode.
A headline number can conceal that the failures are concentrated in the highest-stakes cases. Reframing toward per-task performance and consequence gives the sponsor what they actually need to make a go or no-go decision, without dismissing a reasonable question.
✗Provide the number without qualification, since executives need simplicity.
This trades the sponsor's ability to make an informed decision for convenience, and leaves the architect accountable for what the number concealed.
✗Decline to provide any metric until the system is fully deployed.
Unhelpful and obstructive. Pre-deployment evaluation is both possible and expected.
✗Provide the highest number produced by any evaluation run.
Selectively reporting the best result is a misrepresentation, and it will not survive contact with production.
4. What is the primary purpose of a pilot phase before scaling an agentic deployment across an organization?
✓To discover where real usage diverges from the assumed workflow, and to surface failure modes and adoption barriers while the blast radius is small.
Pilots exist to buy information cheaply. Real users apply a system in ways design sessions never anticipate, and finding that out at ten users rather than a thousand is the entire value of the phase.
✗To demonstrate the technology to stakeholders before committing budget.
A demo may be a side benefit but is not the purpose. A pilot that only demonstrates, without measuring or learning, has been wasted.
✗To allow the model to learn the organization's data before full rollout.
The model does not learn from usage. Any improvement across a pilot comes from changes the team makes to prompts, tools and workflow.
✗To satisfy a procurement requirement for a trial period.
A procurement formality is not an engineering purpose, and treating it as one produces a pilot that measures nothing.
5. An architect is asked to help fifty developers adopt Claude Code consistently across many repositories. Which approach scales best?
✓Establish shared conventions as durable artefacts — CLAUDE.md templates, reusable skills and commands, and reviewed permission defaults — so good practice is the default rather than tribal knowledge.
Encoding practice into artefacts that ship with the repositories means every developer inherits it without needing to have attended a session. Training alone decays; artefacts persist and can be improved centrally.
✗Run a one-off training session and rely on developers to remember the guidance.
One-off training does not survive staff changes or the passage of time, and produces exactly the inconsistency the question asks to avoid.
✗Require every use of the tool to be reviewed by the architect personally.
This makes the architect a bottleneck for fifty developers and does not scale by construction.
✗Restrict the tool to a small group of senior developers.
This avoids the enablement problem by forgoing most of the benefit, rather than solving it.
6. Several teams have independently built MCP servers that expose overlapping access to the same internal systems. What should the architect do?
✓Consolidate onto shared, owned servers with clear scopes and a defined ownership model, so tools are consistent, auditable and maintained.
Duplicated integrations drift apart, apply inconsistent permissions and multiply the audit surface. Consolidating with explicit ownership is what makes the tool layer governable — the same reasoning that applies to any shared internal platform.
✗Allow each team to maintain its own server, since autonomy speeds delivery.
Autonomy is valuable but this particular duplication concentrates risk: several independently maintained paths into the same sensitive system, with no consistent permission model.
✗Prohibit MCP servers entirely and require direct API integration in every application.
This discards the reusability that motivated the protocol and pushes the same duplication down a layer.
✗Merge all servers into one that exposes every possible tool without scoping.
Consolidation without scoping creates an over-privileged surface where every consumer inherits every capability — worse than the fragmentation it replaces.
7. An agent occasionally enters long unproductive loops, repeating similar tool calls without progressing. Which architectural control addresses this most directly?
✓Impose explicit budgets — maximum iterations, wall-clock time and tool calls — with a defined behaviour when a budget is exhausted.
Loop detection through reasoning alone is unreliable, because a stuck agent is by definition not reasoning well about its own state. Hard budgets bound the failure regardless of cause and give a deterministic exit, which is what production needs.
✗Instruct the agent in the system prompt not to repeat itself.
A useful hint, but it is guidance rather than enforcement and will not reliably stop the behaviour it describes.
✗Switch to a larger model so it is less likely to become confused.
This may reduce frequency but provides no bound. An unbounded loop on a more expensive model is a more expensive unbounded loop.
✗Remove the agent's tools so it cannot call anything repeatedly.
This eliminates the capability rather than governing it, leaving an agent that can no longer do its job.
8. An architect is designing a multi-agent system where a coordinator delegates to specialized subagents. Which two design decisions most affect reliability? (Select two.)
✓Defining precisely what each subagent returns to the coordinator, so results are structured and comparable rather than free-form prose.
The coordinator has to act on what it receives. Unstructured returns force it to re-interpret prose at every step, which compounds error across the hierarchy. A defined return contract is what keeps a multi-agent system tractable.
✓Scoping each subagent's tools and permissions to only what its task requires.
Narrow scope limits both accidental damage and the reach of any injected instruction, and it improves tool selection by shrinking the space of choices. It is the multi-agent expression of least privilege.
✗Ensuring every subagent uses the same model tier as the coordinator.
Uniformity is not a reliability property. Matching tier to task difficulty is usually the better engineering choice, and mixed tiers are common in practice.
✗Allowing subagents to invoke each other freely to maximize flexibility.
Unconstrained mutual invocation makes control flow unpredictable and debugging extremely difficult, and it invites cycles. Delegation should follow a defined structure.
7 more questions in the app
Practise the full 15-question set with a timer, scoring and progress tracking.