CCAR-P questions and answers — Stakeholders, Lifecycle and Enablement

13 practice questions across the two domains that are least like Foundations: Stakeholder Communication and Lifecycle (14%) and Developer Productivity and Operational Enablement (7%). Neither has a Foundations equivalent, and technical candidates routinely under-prepare them.

Stakeholder Communication and Lifecycle

Question 1

A stakeholder requests "a chatbot for policy questions". What is the correct first response?

1. Scope the chatbot and estimate delivery
2. Convert the stated solution back into the underlying problem — what decision it supports, what happens when it is wrong, what constraints apply
3. Explain that chatbots are an outdated pattern
4. Build a prototype to gather feedback

Answer: B. Requests arrive as solutions. Designing straight from the stated solution risks building the wrong thing correctly. A prototype may follow, but only once you know what problem it is testing.

Question 2

How should an architect present a design decision to a steering group?

1. A single recommendation, to avoid confusing non-technical stakeholders
2. Two or three viable options with their cost, latency, accuracy and risk profiles, plus a recommendation and its reasons
3. A technical deep-dive so the group can judge for themselves
4. The cheapest option, since budget usually decides

Answer: B. Presenting options with quantified trade-offs lets the decision-maker own a decision rather than ratify yours — which matters when the trade-off later turns out to bite. A single recommendation hides the alternatives; a deep-dive shifts the burden to people not equipped for it.

Question 3

Which can legitimately appear in an SLA for a Claude-based system?

1. The model will not produce incorrect output
2. Accuracy at or above a threshold measured against a defined evaluation set, plus escalation turnaround times
3. All queries answered correctly within 2 seconds
4. Quality will not degrade over time

Answer: B. You can commit to what you measure and control: availability, latency percentiles, accuracy against a defined suite, escalation turnaround, and time to detect degradation. Correctness guarantees on arbitrary inputs and promises that drift will not occur are not commitments you can honour.

Question 4

Which document has the most value two years after a system is built?

1. The original project plan
2. Decision records stating what was chosen, what was rejected and why
3. The initial cost estimate
4. The kick-off presentation

Answer: B. The rationale is what a future team needs when it asks why the system is not agentic, or why a control exists. Plans and estimates describe an intention that events have long since overtaken.

Question 5

A business sponsor asks for a guarantee that the system will never send an incorrect figure to a customer. What is the professional response?

1. Agree, and add more guardrails
2. Convert it into a measurable accuracy target with an agreed evaluation method and a review path for the cases that fall short
3. Explain that LLMs are probabilistic and decline the request
4. Agree, on the condition that the output is always reviewed

Answer: B. Neither over-promising nor refusing. The professional move turns an absolute into something measurable and governable — a target, a method of measuring it, and what happens to the residual. Blanket review of everything is a real option only if it is affordable, and the stem did not establish that.

Question 6

What should a lifecycle plan for a Claude-based system include?

1. A support contact and a bug tracker
2. Scheduled eval re-runs against current model versions, periodic refresh of the eval set, re-examination of the original constraints, and an explicit keep, rework or retire decision point
3. An annual budget review
4. A commitment to upgrade to each new model version

Answer: B. Systems built on models age in a way conventional software does not — the model changes, the data shifts, the regulation moves. Automatically upgrading every version is as unmanaged as never upgrading; the point is the scheduled, evidenced decision.

Question 7

Which limitation should be communicated to stakeholders before go-live rather than after?

1. The programming language used
2. That accuracy cannot be guaranteed, that the system cannot reach data it is not connected to, and that certain decisions require a human by regulation
3. The model's parameter count
4. The team's sprint cadence

Answer: B. These three shape what the business can promise its own customers. Discovering them at go-live destroys credibility the design deserved to keep, and it is the specific communication failure this domain tests.

Question 8

A system is being handed to an operations team that did not build it. What indicates the handover is ready?

1. The code is documented and repository access is granted
2. Decision records, a runnable eval suite defining correctness, an operational runbook with known failure modes, and a data-flow and compliance map
3. The original team remains available for questions
4. The system has run without incident for a month

Answer: B. Handover readiness is about whether someone else can operate, diagnose and change the system. Availability of the original team is a crutch that expires, and an incident-free month says nothing about whether anyone else could handle the first incident.

Question 9

Your availability commitment for a Claude-based service is bounded by what?

1. Your own infrastructure only
2. The model provider's availability, plus your retrieval layer, plus your own infrastructure
3. The model provider's availability only
4. Nothing, if you implement retries

Answer: B. You cannot promise more availability than the weakest link in your dependency chain. Retries smooth transient failures but do not raise the ceiling, and forgetting the retrieval layer is a common omission in these questions.

Developer Productivity and Operational Enablement

Question 10

An organisation needs a policy that no Claude Code session may write to a particular directory, enforced everywhere and not overridable by individual teams. Where does it belong?

1. A managed policy CLAUDE.md
2. permissions.deny in managed settings
3. Each project's .claude/settings.json
4. A documented team convention

Answer: B. CLAUDE.md is context: it guides and guarantees nothing. Settings rules are enforced by the client regardless of what Claude decides, and managed settings cannot be overridden by project or user files. Project settings can be edited by anyone with commit access.

Question 11

A CI pipeline using Claude Code produces different results on different runners. What is the fix?

1. Pin the model version only
2. Add --bare, so the run does not load host-specific hooks, plugins, MCP servers, memory or CLAUDE.md
3. Increase the turn limit
4. Run the pipeline on a single dedicated runner

Answer: B. Without --bare, a headless run loads whatever configuration exists on that machine, so a teammate's personal setup can change pipeline behaviour. Pinning the model helps but does not address configuration discovery; one dedicated runner hides the problem rather than fixing it.

Question 12

Which arrangement best standardises how a team builds against an internal service?

1. A shared document describing the API
2. A project-scoped .mcp.json committed to the repository, with ${VAR} expansion for credentials
3. Each developer configuring the server locally
4. A shared set of credentials distributed by email

Answer: B. Project scope commits the configuration so everyone gets it on clone, and environment expansion keeps secrets out of the committed file. Local configuration drifts immediately, documentation is not executable, and shared distributed credentials are a security failure.

Question 13

What most reliably indicates that a team's Claude setup is not sustainable?

1. It uses several subagents
2. The working configuration exists only in one engineer's environment and head
3. It relies on MCP servers
4. It uses a pinned model version

Answer: B. An undocumented, unshared setup is a single point of failure disguised as expertise. Committed configuration — rules, settings, skills, agents and .mcp.json — is what makes a team's capability survive one person's departure.

← Previous: Questions & answers — Domain 5  |  Next: Facts to memorise →