CCAR-P Practice Question: Developer Productivity and Operational Enablement
A developer enablement team is building an internal prompt playground so engineers can iterate on Claude prompts without writing API code. They want the playground to reflect production behavior and avoid surprising cost overruns. (Choose two.)
⚠ Common exam trap
The trap here is optimizing for frictionless access with unlimited keys while ignoring that unbounded experimentation is the exact cost risk the team is trying to avoid.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Pin the playground to the same model version and system prompt that production uses, so experiments reflect real behavior.
A playground is only useful if its results predict production, so the model version and system prompt must match what ships. Cost safety comes from automated controls: per-user quotas and usage dashboards. Together these give engineers fast, trustworthy iteration without exposing the organization to unbounded spend. Unlimited keys, disabled streaming, and ticket-gated testing each fail either the parity goal or the velocity goal.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Disable streaming in the playground to reduce token consumption.
Why it's wrong here
Streaming affects how tokens are delivered, not how many are generated or billed. Disabling it would not reduce cost and would make the playground behave differently from production tools that stream. It also degrades the interactive experience engineers expect. The meaningful cost controls are quotas and visibility, not turning off a delivery mechanism that has no bearing on token totals.
- ✗
Require engineers to file a ticket for every prompt test so usage is reviewed before execution.
Why it's wrong here
Ticket-gated testing destroys the fast iteration loop a playground is meant to create. Review before every run adds latency that pushes engineers to bypass the tool entirely, undermining adoption. Cost control should come from quotas and dashboards that operate automatically, not from manual approvals. Production parity plus automated budgets keeps velocity high while keeping spend predictable.
- ✗
Give every engineer an unlimited personal API key so experimentation is never blocked.
Why it's wrong here
Unlimited personal keys remove the very guardrail the team wants. Prompt iteration can generate large volumes of tokens quickly, and without per-user budgets or quotas, costs can spike unpredictably. The goal is to enable experimentation while keeping spend visible and bounded. Centralized keys with per-user quotas, plus usage dashboards, achieve both goals better than unrestricted credentials.
- ✓
Pin the playground to the same model version and system prompt that production uses, so experiments reflect real behavior.
Why this is correct
Experiments only transfer to production if the model version and system prompt match. A playground running a different model or a divergent system prompt produces results that mislead engineers and cause rework. Pinning both keeps the feedback loop honest and makes prompt changes meaningful. It also prevents the common failure where a prompt succeeds in the playground but behaves differently once deployed.
- ✓
Enforce per-user token quotas and surface usage dashboards so experimentation stays within budget.
Why this is correct
Quotas bound the blast radius of runaway experiments, and dashboards make consumption visible before it becomes a finance surprise. Together they let engineers iterate freely within agreed limits while giving the platform team the data to tune budgets. This directly addresses the cost-overrun concern without blocking legitimate work, which is why it pairs with production parity as a required control.
Quick reference
RAID Level Comparison
| RAID Level | Min Disks | Fault Tolerance | Read | Write | Usable Capacity |
|---|---|---|---|---|---|
| RAID 0 | 2 | None | Excellent | Excellent | 100% |
| RAID 1 | 2 | 1 disk | Good | Moderate | 50% |
| RAID 5 | 3 | 1 disk | Good | Moderate | 67–94% |
| RAID 6 | 4 | 2 disks | Good | Lower | 50–88% |
| RAID 10 | 4 | 1 disk per mirror | Excellent | Good | 50% |
RAID is not a backup strategy — it protects against disk failure but not against accidental deletion, ransomware, or site-level events.
About these practice questions
One of 262 original CCAR-P practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Anthropic exam blueprint
This CCAR-P practice question is part of Courseiva's free Anthropic certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CCAR-P exam.