Claude Certified Architect – Professional (CCA-P) exam guide and free practice test

Why: An ambiguous executive mandate must be translated into a scoped, measurable problem before any architecture or model decision is made. Discovery identifies the highest-value process and the criteria that will prove success.

Architect-level work starts by converting 'transform claims with AI' into a concrete target: a specific workflow, a baseline, and agreed success metrics. Option A commits to the most complex and least predictable architecture before anyone knows which process matters or how success will be judged. Option B produces diffuse usage data but no defensible business case, and broad rollouts without scope are how AI programs stall. Option D makes a model-tier decision before requirements exist; model selection follows from the scoped problem, not the other way around. Exam tip: when a scenario opens with a vague executive ask, the best answer almost always involves scoping and success criteria before any build or model choice.

Why: Three hosts needing the same connectors is the canonical MCP case: build each integration once as an MCP server and reuse it across every Claude host, with one place to maintain schemas and access control.

MCP standardizes the tool interface so an integration is written once and consumed by any compliant host, which directly eliminates the triplicated connector code. Option A keeps the duplication that is causing the problem, and per-team schemas will drift apart over time. Option C introduces agent-to-agent handoff for what is plain data access, adding latency and a new orchestration layer nobody asked for. Option D replaces live transactional queries with stale replicated data and cannot support writes like updating a ticket. Exam tip: when a scenario emphasizes multiple applications or teams sharing the same integrations, the answer is almost always MCP; direct tool definitions win when a single application needs tight control.

Why: LLM-as-judge is a scalable middle ground, but it is itself a model output — its agreement with human labels on a sample must be established before its grades carry weight.

An LLM judge only earns trust by demonstrating agreement with the gold standard: grade a human-labeled sample with the judge, measure alignment, and refine the judge rubric until agreement is acceptable. Option B discards every disagreement, which silently biases the measured population toward easy cases and still never establishes that either judge matches human judgment. Option C confuses explanation with validation — a judge can produce fluent reasoning for a wrong grade, so self-justification proves nothing. Option D abandons the method entirely, yet accuracy and policy compliance of free-form support text cannot be reduced to exact-match assertions. Exam tip: whenever LLM-as-judge appears, look for the answer that calibrates it against human labels.

Why: Approval gates belong on irreversible, high-consequence actions. Refunds cannot be recalled once paid, so they need a human in the loop; reroutes are cheap to undo and can run autonomously under monitoring.

Reversibility is the primary axis for deciding where humans sit in an agent workflow: an action you can undo cheaply can be automated and monitored, while an action you cannot undo needs approval before execution. Option A satisfies the CFO but destroys the automation value for reroutes, which are the high-volume, low-risk action the agent exists to handle. Option B gets the analysis backwards by treating physical-versus-digital as the risk axis when the real axis is recoverability — a mistaken reroute is corrected with another reroute, while a mistaken $50,000 transfer is gone. Option C leaves an unrecoverable financial action with no pre-execution control, so monitoring would only tell you about losses after they occur. Expect the exam to hide the reversibility signal inside the scenario wording, as it does here with 'unrecoverable once transferred'.

Why: "We need a chatbot" is a solution-shaped request, not a problem statement. The architect's first job is structured discovery of the actual business problem, current process, volumes, and error tolerance before proposing or building anything.

Architect-level engagements start by eliciting the real problem: perhaps most scheduling friction comes from insurance verification or no-show follow-ups, in which case a patient-facing chatbot solves the wrong thing. Option A jumps to building before knowing what success looks like, and a prototype anchored on the wrong problem tends to lock the engagement into that framing. Option B commits to an integration architecture before knowing whether conversational scheduling is even the right intervention. Option D is a reasonable later step, but a build-versus-buy comparison is meaningless before requirements exist to compare against. Exam tip: when a stakeholder names a technology instead of a problem, the correct first move is almost always discovery, not delivery.