Anthropic CCAR-P Claude Certified Architect - Professional Exam Practice Test

Responsible deployment requires users to receive an accurate representation of the system with which they are interacting. Option C provides that transparency while also establishing a practical escalation path. Disclosure should be proportionate to the material role AI plays, expressed in language appropriate to the audience, and aligned with organizational policy and applicable regulatory obligations.

A documented human-contact route is important when the assistant cannot resolve an issue, produces a disputed result, encounters a high-impact exception, or handles a matter requiring human authority. Anthropic’s Responsible Scaling Policy recognizes escalation to human reviewers as an appropriate safeguard for edge cases and situations requiring human judgment. Responsible Scaling Policy

Options A and D intentionally conceal material AI involvement from affected users, weakening informed decision-making, auditability, and trust. Option B is also unsuitable because transparency does not require revealing proprietary prompts, confidential controls, or internal security mechanisms; however, it does require an honest explanation of AI involvement and the system’s operational role.

The correct design combines disclosure, understandable limitations, human escalation, and records demonstrating that the organization’s transparency requirements are consistently applied.

Study Guide references/topics: AI transparency; informed user interaction; human escalation; responsible deployment; disclosure policy; operational accountability.

===============

Executive sponsors generally need architecture decisions translated into business significance. The briefing should explain what outcomes the retrieval architecture enables, why the chosen approach is valuable, which material trade-offs were accepted, and what major risks require awareness or sponsorship. This allows the executive to assess strategic alignment, investment value, and organizational exposure without becoming immersed in component-level implementation details. Option A is more appropriate for architects and engineering teams conducting a technical review. Option C is primarily suited to product and program stakeholders managing features, scope, and roadmap dependencies. Option D is designed for security, compliance, and risk-governance audiences requiring detailed control evidence. Although those perspectives remain important, option B provides the concise, outcome-oriented framing needed for an executive architectural decision summary.

================

Prompt caching reduces repeated input processing when a stable system prefix is reused, directly lowering input cost and processing latency. Model routing provides the second optimization: routine cases can use a faster, lower-cost model, while difficult cases retain access to the more capable model. The routing policy must be validated against representative evaluations to confirm that quality remains within the required threshold. Increasing max_tokens can increase output cost and generation time. Retrieving the complete corpus and adding examples to every request both enlarge the input, worsening latency and token consumption. Anthropic identifies prompt caching as a cost-and-latency optimization and recommends selecting a model according to the workload’s quality, speed, and economic requirements. Prompt caching; reducing latency

A direct call to the existing stable HTTP endpoint is the simplest mechanism that satisfies the stated requirements. The interaction is stateless, requires only one tool invocation, and has a strict latency objective. Adding session management, message-bus translation, or another model-mediated agent would introduce unnecessary network hops, operational dependencies, failure modes, and processing latency.

The assistant’s tool implementation should validate input parameters, authenticate through a server-side credential mechanism, apply narrowly scoped authorization, set explicit timeouts, and validate the pricing response before returning it to Claude. Credentials must never be supplied by or exposed to the model. Appropriate logging should capture request attribution, endpoint outcome, and timing without unnecessarily recording sensitive data.

Anthropic describes the Claude API as a RESTful interface and supports custom tools in which the application executes the requested function or API operation. Claude API Overview, Tool Use Overview

MCP could be justified when standardized discovery or reuse across clients is required, but the scenario already supplies a stable API and does not establish that additional requirement.

Study Guide references/topics: Protocol selection; direct API integration; stateless calls; latency minimization; scoped credentials; avoiding unnecessary agentic complexity.

===============

The required control is best implemented through layered prevention. The system prompt should explicitly classify personalized investment recommendations as out of scope, instruct Claude not to recommend particular securities or transactions, and provide standardized refusal language. Fixed refusal behavior reduces ambiguity and gives the model a clear alternative response when users request prohibited advice or attempt to reframe it indirectly.

An output classifier supplies an independent enforcement layer after generation but before delivery. It should detect prohibited recommendation language, individualized buy-or-sell instructions, portfolio allocations, and equivalent regulated content. A detected violation must block or replace the response rather than merely record it. This protects against prompt circumvention, unexpected phrasing, and occasional model noncompliance.

Increasing temperature makes responses less predictable and weakens control reliability. Session-length limits regulate volume, not content. SIEM logging is valuable for monitoring, investigation, and compliance evidence, but it is detective rather than preventative: the prohibited recommendation may already have reached the customer.

The completed design should evaluate both layers using adversarial prompts, paraphrases, multi-turn escalation, and classifier false-negative testing.

Study Guide references/topics: [Mitigating jailbreaks and prompt injections](https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/mitigate-jailbreaks); layered guardrails; explicit scope boundaries; standardized refusals; output classification; pre-delivery enforcement.

===============

Option B targets two major contributors to per-turn latency: retrieved-context size and repeated prompt processing. Reducing retrieval to an empirically validated top-k limits the tokens Claude must process while preserving the passages that historically provide sufficient answer coverage. Caching the stable system-prompt prefix avoids repeatedly processing identical instructions.

Anthropic’s latency guidance recommends choosing an appropriate model and reducing unnecessary input and output tokens. Its prompt-caching documentation explains that caching reusable prompt prefixes can reduce both repeated processing cost and latency. Reducing Latency, Prompt Caching

The retrieval depth must be selected through evaluation rather than arbitrary truncation. The team should compare answer quality, retrieval recall, latency, and failure rates across candidate values and retain escalation logic for complex queries requiring deeper retrieval.

Option A removes an applicable latency optimization. Option C maximizes context consumption regardless of demonstrated benefit. Option D deliberately selects the slowest model class even though routine-turn quality already meets requirements.

Study Guide references/topics: Latency optimization; top-k retrieval; prompt caching; token reduction; quality–latency evaluation; adaptive retrieval.

===============

The absence of company-specific training does not establish unbiased behavior. A foundation model may reflect demographic associations or unequal treatment patterns originating from pretraining data, model behavior, prompt framing, retrieval content, or the surrounding decision workflow. Because candidate screening can materially affect employment opportunities, the complete system must be evaluated across relevant protected groups before deployment. Appropriate measures include selection-rate differences, false-positive and false-negative rates, calibration, intersectional slices, and human override patterns. Disclosure that AI is used does not replace empirical fairness testing. Protected-class labels need not have been explicit in training data for proxy variables or inferred attributes to produce disparities. Provider policies similarly do not validate a customer’s specific implementation. Anthropic system cards document discriminatory-bias evaluations, reinforcing the need for application-level testing. Claude model system card

Tool Search applies progressive discovery to a large tool catalog. Instead of inserting every MCP tool’s complete JSON schema and description into the initial context, Claude receives limited discovery information and loads the full definitions only when a task requires them. This preserves the available context for instructions, repository content, conversation history, and tool results without removing the underlying capabilities.

Anthropic’s Claude Code documentation states that Tool Search keeps MCP context usage low by deferring tool definitions until Claude needs them. Only the tools actually selected enter the working context. Claude Code MCP Tool Search

Anthropic’s advanced-tool-use guidance also describes conventional multi-server configurations consuming tens of thousands of tokens before work begins, while on-demand discovery substantially reduces that overhead. Advanced Tool Use

Option B solves context pressure by destroying required functionality. Option C worsens the constraint by adding more prompt tokens. Option D expands the exact source of context bloat.

The team should also improve server and tool descriptions so discovery returns the correct tools, monitor tool-selection quality, and keep frequently required foundational tools non-deferred only when evaluations justify the additional context cost.

Study Guide references/topics: MCP scaling; Tool Search; progressive discovery; deferred schemas; context-budget management; tool-selection accuracy.

===============

An Architecture Decision Record is designed to preserve a significant architectural choice in a concise, durable, and reviewable form. The context explains the problem, constraints, and forces that shaped the decision. The decision section records the selected approach. Alternatives demonstrate that other viable options were evaluated, while consequences identify benefits, costs, limitations, operational obligations, and residual risks. The date and authors establish accountability and historical sequence.

This structure supports audit because a reviewer can trace why a model, integration pattern, retrieval architecture, security boundary, or deployment approach was chosen. It also supports onboarding by preventing new team members from interpreting intentional design choices as arbitrary implementation details.

A slide deck may communicate a decision at a meeting but is weak as the sole authoritative record when it lacks written rationale. A code comment is too localized and may not capture system-level implications or rejected alternatives. A verbal conversation creates no durable evidence and depends entirely on individual memory.

The ADR should be version-controlled, linked to affected requirements and implementation artifacts, assigned an owner, and reviewed when its assumptions or operating conditions materially change.

Study Guide references/topics: Architecture Decision Records; decision context; alternatives; consequences; auditability; onboarding; lifecycle review.

===============

Unrestricted Bash access exposes filesystem, credential, process, network, package-management, and potentially infrastructure-administration capabilities across every repository. Option C applies least privilege by identifying the commands genuinely required by approved workflows and permitting only those patterns. Explicit deny rules should protect destructive commands, sensitive files, credential stores, deployment systems, and other prohibited operations.

Anthropic’s permission system supports allow, ask, and deny rules, with deny evaluated before ask and allow. It also warns that command patterns intended to constrain network utilities can be fragile, so stronger controls such as WebFetch domain restrictions, hooks, and sandbox boundaries may be required. Claude Code Permissions

Enterprise configuration should combine managed baseline restrictions with project-specific permissions where necessary. High-impact commands should remain subject to confirmation, and sandboxing should provide operating-system-level filesystem and network containment.

Options A and D deliberately enlarge the attack surface. Option B treats configuration simplicity as more important than enterprise security and fails to account for prompt injection, accidental commands, compromised repositories, or excessive human approval. The configuration should be narrow, auditable, centrally governed, and validated against real development workflows.

Study Guide references/topics: Claude Code permissions; Bash restrictions; least privilege; managed controls; explicit deny rules; sandboxing; enterprise rollout security.

===============

Implementation-ready documentation must provide both executable specifications and preserved architectural reasoning. Option A supplies the contracts an implementation team needs to build components independently: configuration schemas, accepted inputs, produced outputs, validation requirements, and integration boundaries. These details prevent teams from inventing incompatible assumptions about data structures, tool behavior, error handling, or component ownership.

Option B complements the technical contracts with a decision log. Recording the selected design, underlying constraints, alternatives considered, and reasons for rejection enables implementers to distinguish deliberate architectural decisions from accidental omissions. It also prevents previously rejected approaches from being reintroduced without new evidence.

A high-level business narrative in Option C may explain purpose but cannot direct component-level implementation. Contact information in Option D provides an escalation route, but documentation is not sufficient if routine progress still depends on the architect’s availability. Option E records activity rather than a decision; a model list without the selected model and selection rationale leaves critical cost, latency, capability, and evaluation assumptions unresolved.

A strong handoff package should permit implementation, testing, and support teams to proceed while escalating only genuinely new architectural questions.

Study Guide references/topics: Architecture documentation; interface contracts; configuration schemas; Architecture Decision Records; implementation handoff; decision traceability.

===============

Empirical model testing requires a defined decision frame. Option D must occur first because the quality threshold, acceptable latency, expected request volume, and associated cost envelope determine what constitutes a successful result. Without these criteria, a representative-sample test can produce measurements but cannot support a defensible selection.

Option C is the next upstream step. Known model capabilities and the workload profile are used to identify a plausible candidate rather than testing models arbitrarily. Anthropic’s model-selection guidance recommends evaluating capability, speed, cost, and effort requirements before narrowing the candidate set. Choosing the Right Model

Option A occurs after empirical testing because the architect cannot know which lightest model consistently meets the quality bar until sample results have been evaluated. Option B belongs to ongoing lifecycle management after a new version becomes available. Option E is a deployment-governance activity that follows successful model selection, security review, and readiness validation.

The correct sequence is: define workload criteria, shortlist candidate models, run a representative evaluation, compare quality and operational metrics, select the least costly model that reliably satisfies all gates, and periodically retest the decision.

Study Guide references/topics: Requirements-driven model selection; representative sampling; quality thresholds; latency and volume requirements; capability–cost trade-offs; model lifecycle reassessment.

===============

Yes, Yes, No, Yes, No

Zero-shot prompting is a reasonable baseline for a clearly defined closed-set classifier because the model receives both the permissible labels and their meanings. Performance should then be measured against an evaluation set before additional prompt complexity is introduced. Few-shot examples are also sound for extraction because examples containing the exact field names demonstrate the required schema and reduce formatting ambiguity. Anthropic identifies examples as one of the most reliable methods for steering output format, structure, and consistency. Prompting Best Practices

Chain-of-thought is not an unconditional default. Additional reasoning is appropriate when the task requires substantive decomposition or complex judgment, but routine classification and extraction may gain little while consuming more tokens and increasing latency. The technique should be selected according to evaluated task requirements.

An even-handed comparison governed by explicit criteria mitigates leading-question bias by requiring symmetrical treatment of alternatives rather than presupposing a preferred conclusion. Finally, prompt validation is model-specific. New model versions may follow instructions differently, change formatting behavior, alter tool selection, or produce different latency and cost characteristics. Anthropic’s migration guidance consequently recommends reevaluating prompts and workloads against the new baseline. Model Migration Guide

Study Guide references/topics: Zero-shot prompting; few-shot examples; reasoning techniques; neutral framing; model migration and regression evaluation.

===============

Effective documentation begins with audience analysis and structural planning. Identifying the audience determines the required technical depth, terminology, decision context, and operational emphasis. Defining the questions the guide must answer prevents sections from becoming generic descriptions. The outline then establishes complete coverage across architecture overview, component responsibilities, interface contracts, dominant flows, operational runbooks, and known limitations. Translation occurs only after stable source content exists. Implementation-team validation also follows an initial draft because there must be material to review. Version control, reviewers, and cadence are important governance controls, but they do not replace the two content-planning activities required before section drafting. The guide should be planned around the decisions and tasks its intended readers must perform.

Model Stage, Post-Processing, Post-Processing, Model Stage, Pre-Processing, Pre-Processing

Pre-processing prepares source material before Claude receives it. Optical character recognition converts scanned invoice images into machine-readable text. Because PII redaction is explicitly performed before model invocation, it also belongs in pre-processing. Additional activities at this layer can include file validation, malware scanning, normalization, page separation, and metadata extraction.

The model stage contains tasks requiring Claude’s language-understanding capability. Classifying the invoice type involves interpreting textual and contextual features, while extracting structured invoice fields requires mapping unstructured content into defined business attributes.

Post-processing verifies and commits the model’s result. Schema validation confirms that required fields exist, data types are correct, enumerated values are permitted, and structural constraints are satisfied. Persistence must occur only after validation and any required human review because the system of record should not receive malformed or unapproved model output.

This decomposition separates probabilistic inference from deterministic processing. OCR, redaction, validation, and persistence do not need to be delegated to Claude when conventional components can execute them more predictably. The resulting architecture reduces model workload, strengthens privacy controls, improves auditability, and prevents unvalidated output from directly changing authoritative records.

Study Guide references/topics: Task decomposition; pre-processing; model inference; post-processing; deterministic validation; privacy-by-design; system-of-record protection.

===============

A workflow is appropriate when processing stages and transitions are known in advance. Metadata extraction, classification, summarization, and persistence can be represented as deterministic nodes with explicit schemas, validation rules, retry policies, and failure handling. This provides predictable execution, cost, observability, and testability without paying for repeated model-driven planning. Anthropic’s Building Effective AI Agents distinguishes workflows, where predefined code paths control execution, from agents, where the model dynamically determines its process. Option A reaches the correct pattern for an incorrect reason: workflows and agents can both invoke tools. Options B and C introduce unnecessary autonomy and make unsupported claims about consistency or universal accuracy.

Study Guide references/topics: Workflow versus agentic patterns; deterministic orchestration; batch processing; structured outputs; predictable cost; error handling.

A complete handoff package must help different stakeholders understand, operate, troubleshoot, and evolve the Claude-based solution. An architecture overview explains the system’s structure and responsibilities, while Architecture Decision Records document important decisions, alternatives, and trade-offs. Component-level diagrams provide implementation context without forcing maintainers to reconstruct dependencies from source code. Operational runbooks and an on-call playbook enable reliable incident detection, diagnosis, escalation, and recovery. Documenting known limitations is particularly important for Claude applications because model behavior can vary with prompts, context, input distribution, and external dependencies. Options B, C, and D each provide only a partial or temporary understanding of the system. They would create knowledge gaps, increase operational risk, and make future maintenance dependent on individuals rather than durable organizational documentation.

================

Strong decision communication must explain both how the decision was reached and how it will remain governed. Option D provides the reasoning structure: the alternatives considered and the criteria used to compare them. This allows reviewers to verify that capability, cost, latency, security, maintainability, integration complexity, and business outcomes were evaluated consistently rather than selectively.

Option A establishes lifecycle accountability. Architectural decisions depend on assumptions about requirements, models, data, regulations, usage volume, and operational constraints. Naming an owner and review cadence ensures the decision is reconsidered when those assumptions materially change.

Option B imposes a meeting mechanism rather than describing decision quality. Mandatory attendance by senior leaders may add delay without improving the clarity or correctness of the record. Option C removes important evidence and increases the chance that rejected approaches will be proposed again without addressing the original objections. Option E can improve consistency and discoverability, but visual standardization alone does not establish substantive architectural communication.

A strong decision record should therefore be evidence-based, audience-accessible, traceable to requirements, explicit about alternatives and consequences, assigned to an accountable owner, and governed by defined review triggers.

Study Guide references/topics: Architectural-decision communication; alternatives analysis; evaluation criteria; decision ownership; review cadence; changing assumptions; lifecycle governance.

Risk-stratified sampling concentrates limited reviewer capacity where error consequences and uncertainty are greatest. All low-confidence and high-impact cases should receive mandatory review, while random sampling of routine high-confidence outputs provides an unbiased signal for drift, unexpected failure modes, and overconfident errors. Complaint-only monitoring discovers defects after harm occurs. Reviewing only high-confidence cases systematically ignores the most dangerous outputs. Universal review provides maximum coverage but contradicts the stated throughput constraint and may create queues that undermine service objectives. The sampling policy should define confidence calibration, impact categories, escalation thresholds, review SLAs, and periodic adjustment based on observed error rates. Reviewer decisions should feed the evaluation dataset so monitoring quality improves over time.

Threat assessment requires an inventory of what must be protected and who or what may threaten it. Asset identification should cover prompts, retrieved documents, credentials, model outputs, audit logs, tools, external systems, and sensitive business or personal data. Sensitivity classifications establish the potential confidentiality, integrity, safety, and availability impact of compromise. Threat actors and attack vectors must then be enumerated so likelihood and impact can be assessed against specific assets. Mitigation recommendations, residual-risk acceptance, ownership, and final documentation follow the analysis; they cannot be completed coherently before the threats are understood. Anthropic’s security transparency materials similarly emphasize maintaining threat models that reflect relevant attacker tactics and techniques. Anthropic Transparency Hub

The observed sequence provides direct causal evidence: the initial connection was interrupted while the operating system awaited authorization, and later attempts succeeded after permission was granted. The correct response is to verify repeatability, document the first-run requirement, and incorporate it into installation or onboarding instructions. Reinstalling the operating system is disproportionate and destroys useful diagnostic state. Disabling permission dialogs weakens endpoint security and bypasses the control rather than addressing expected behavior. Replacing a server that operates correctly after authorization misclassifies a transient initialization condition as a permanent defect. Claude Code uses explicit permission controls to balance capability and safety, so first-use approval behavior should be accommodated rather than suppressed. Claude Code permissions

Option D applies three complementary controls. First, a read-only database credential creates an authorization boundary outside the model; prompt instructions alone cannot convert that credential into write access. Second, restricting the subagent’s tool list reduces capability exposure by preventing the agent from selecting unrelated or unnecessarily privileged operations. Third, explicit human confirmation creates a deliberate approval gate before any exceptional data-changing action is executed.

This is defense in depth. If Claude misinterprets a request or processes malicious instructions from untrusted content, the restricted credential and tool configuration limit the available action surface. Human review then protects operations with potentially irreversible production consequences. Logging and audit trails should remain enabled to record the actor, request, tool call, approval, affected records, and outcome.

Anthropic documents that Claude Code begins with read-only permissions in Manual mode and requests approval for actions that modify the environment. Its permission system also supports granular allow, ask, and deny controls for MCP tools and subagents. Claude Code Security, Configure Permissions

Options A and B eliminate least privilege and approval boundaries. Option C removes essential detection and forensic evidence.

Study Guide references/topics: Production database safety; least privilege; read-only defaults; MCP permissions; subagent scoping; human confirmation; auditability.

===============

Option C describes indirect prompt injection combined with an outbound transmission channel. The attacker embeds instructions in content that the assistant treats as evidence. If the model follows those instructions, it can retrieve sensitive information and transmit it through the HTTP tool to an attacker-controlled destination. Authorization to read a document does not automatically authorize external disclosure. The architecture should treat retrieved content as untrusted, restrict outbound domains, separate data access from external communication, apply least-privilege tool permissions, and require approval for sensitive transmissions. Options A, B, and D describe normal authorized behavior without evidence of unintended disclosure. Anthropic specifically warns that combining untrusted content, sensitive data, and network tools creates exfiltration risk. Web-fetch security guidance; handling untrusted tool results

Robust guardrails require both preventive enforcement and continuous empirical validation. Per-role tool allow-lists satisfy the preventive requirement by restricting each authenticated role to explicitly authorized tools. Enforcement must occur in the orchestration or permission layer before execution; relying on the model to decide whether a tool call is authorized is not an adequate security boundary. Anthropic recommends allow-list-based validation and provides permission rules and pre-tool-use controls capable of denying calls before they execute.

Adversarial evaluation with regression tracking supplies the validation component. The evaluation set should include prompt injections, indirect injections, encoded instructions, multi-turn escalation, role-confusion attempts, and requests designed to trigger unauthorized tool use. Guardrail performance must then be measured across releases so that changes to prompts, models, tools, or orchestration logic do not silently reduce protection.

Centralized logging and user feedback are useful detective and lifecycle controls, but neither prevents an unsafe action nor proves guardrail effectiveness. Periodically refreshing refusal wording is also insufficient unless the revised behavior is evaluated against defined safety criteria. The strongest design therefore combines deterministic authorization with adversarial regression testing.

Study Guide references/topics: Claude Code permissions and pre-tool enforcement; tool allow-list guidance; adversarial evaluations; regression testing; least-privilege orchestration.

===============

Alignment is an ongoing governance process rather than a one-time approval. Option D creates a predictable cadence for reassessing objectives, constraints, assumptions, risks, service levels, and success measures as business and technical conditions change. Option E requires disagreements to be surfaced and reconciled explicitly, preserving decision traceability and preventing unresolved conflicts from reappearing during implementation or operation. The routine should document decisions, owners, accepted trade-offs, action items, and conditions that trigger reconsideration. Recording meetings may improve accessibility but does not itself produce alignment. Rotating facilitation is optional and may weaken accountability. Automatically escalating every disagreement to an executive sponsor bypasses normal architectural negotiation and should be reserved for material deadlocks.

Study Guide references/topics: Stakeholder alignment; feedback cadence; assumption management; conflict reconciliation; decision records; lifecycle governance.

Federated authorship allows each domain team to maintain the procedural knowledge it understands while preserving organization-wide trust through a central publication gate. Team authors can update coding standards, review practices, and postmortem procedures without waiting for a single platform group to write every change. Central reviewers can validate ownership, security, tool permissions, duplication, versioning, testing evidence, and compliance before publication. Per-developer or fully decentralized publication creates inconsistent and potentially unsafe Skills. Fully centralized authorship becomes a scalability bottleneck and separates content maintenance from domain expertise. Anthropic describes Skills as packages of instructions, scripts, and resources and warns that repository Skills may grant broad tool access, making formal review essential. Claude Code Skills

Package 1 is designed for security and compliance review because its threat model identifies relevant threats and attack paths, its residual-risk register documents the risks remaining after controls, and its control-mapping table connects safeguards to organizational or regulatory requirements. Package 2 is designed for the product manager because delivered capabilities and roadmap dependencies directly support prioritization, release planning, sequencing, and lifecycle ownership. An engineering implementation team would ordinarily need component diagrams, interface contracts, configuration schemas, deployment instructions, and operational runbooks rather than primarily risk-governance artifacts. An executive sponsor generally needs a concise outcome, cost, risk, and decision summary instead of feature-level dependency details. Effective architecture communication must therefore adapt the content and level of detail to each audience’s responsibilities and decision rights.

Workflow improvement depends on where assistance is delivered, not solely on the underlying model. IDE integration makes code, selections, diagnostics, diffs, and repository context available at the point where developers work. This reduces context switching and avoids repeatedly transferring code between systems. Routing every request through Slack introduces an additional interaction surface, separates assistance from development context, and increases friction. A Slack record may support auditability, but it does not outweigh the stated productivity objective, and equivalent audit data can be captured through approved telemetry and repository history. Notifications do not inherently improve engineering velocity. Anthropic’s Claude Code integrations are designed to place agentic coding capabilities directly within terminal and IDE workflows.

The pilot must test a deliberately designed workflow, not technology added without role boundaries. Option B identifies where Claude provides measurable value and where approval, accountability, or consequential decisions must remain human responsibilities. Option E establishes the technical environment required for consistent pilot execution: repository-shared MCP servers, scoped permissions, specialized subagents, and persistent project instructions. Iteration in Option D necessarily follows observed pilot findings. Formal approval from every manager is unnecessarily broad unless required by organizational governance. Complete runbooks and final handoff documentation mature after the workflow has been validated, although essential pilot procedures must exist. Anthropic documents project-level instructions, permissions, MCP servers, and subagents as complementary mechanisms for team workflows. Claude Code extension overview

Persist the validated output for downstream consumption and audit — Output Handling

Order prompt sections so cacheable content appears before per-request content — Prompt Construction

Summarize prior conversation history when full history is no longer needed — Input Preparation

Validate the model’s structured output against the expected schema — Output Handling

Move stable repeated content into a cacheable prefix at the beginning of the prompt — Prompt Construction

Trim retrieved passages to spans relevant to the user’s question — Input Preparation

Input preparation determines what evidence and history should enter the request, so summarization and retrieval trimming belong there. Prompt construction determines ordering and cache boundaries; stable repeated instructions must precede dynamic per-request content to maximize cache reuse. Output handling begins after generation and includes schema validation, persistence, auditing, and downstream delivery. Mixing these responsibilities creates inefficient prompts and weak validation boundaries. Anthropic’s context guidance emphasizes curating the smallest useful context because unnecessary tokens can reduce recall and accuracy. Prompt caching similarly depends on a stable reusable prefix, while structured outputs or schema validation protect downstream systems from malformed responses. Context windows; prompt caching

User scope applies to one engineer across every project and is therefore appropriate for portable personal preferences. Option A fits this definition because an interface theme belongs to the individual rather than to a repository or organization. Option B also fits because Claude Code provides a language setting for the preferred response language, and placing that preference in user scope makes it apply across repositories.

Option C requires managed configuration because an organization-wide security control must be centrally deployed and resistant to individual override. Option D belongs in project scope because repository-specific MCP endpoints must be shared consistently with that repository’s contributors.

Option E describes credential handling rather than merely a preference assignment. Credentials must not be placed in a repository, but avoiding version control alone is insufficient. They must be stored through a supported secure authentication mechanism, protected environment configuration, operating-system credential facility, or approved secrets manager—not inserted as plaintext into an ordinary settings file.

Anthropic defines user scope as affecting one user across all projects, project scope as shared repository configuration, and managed scope as the location for enforceable organizational controls. It also explicitly lists themes and other personal settings as user-scope use cases. Claude Code Configuration Scopes

Study Guide references/topics: User scope; project scope; managed configuration; personal preferences; repository-shared MCP configuration; credential protection.

===============

Project scope is designed for configuration that must be shared by everyone working in a repository. Committing the approved configuration provides versioning, review history, repeatable onboarding, and consistent MCP and permission behavior across the monorepo. User scope is intended primarily for individual preferences and personal rules, so independently maintained user files create configuration drift. Local scope affects only one person in one project and is therefore unsuitable for team-wide distribution. A lead architect’s local configuration cannot establish a shared environment. Claude Code documentation specifically describes .claude/settings.json as the shared project settings file that teams check into source control. Security-critical policies that must not be overridden should additionally be enforced through managed organizational settings rather than relying exclusively on repository configuration. Claude Code: Settings files and precedence

================

A controlled prompt experiment must begin with a falsifiable hypothesis and a predefined primary metric. Option C prevents the team from examining results first and then selecting whichever metric makes the candidate look successful. The metric might measure task accuracy, rubric score, citation validity, escalation rate, latency, cost, or another criterion directly connected to the hypothesis.

Option A determines whether the experiment can detect a practically meaningful improvement. The minimum detectable effect expresses the smallest difference worth acting upon, while the power calculation determines the required sample size. Without this step, the experiment may be too small to detect a real improvement or unnecessarily large and expensive.

Random assignment should then distribute representative traffic between the control and candidate prompts while controlling model version, retrieval configuration, tool availability, and other confounding variables.

Options B and D occur after data collection. Option E follows the completed analysis and decision. The team should also define significance thresholds, stopping rules, guardrail metrics, exclusion criteria, and treatment of repeated observations before launch.

Study Guide references/topics: Prompt A/B testing; hypothesis definition; primary metrics; minimum detectable effect; statistical power; random assignment; decision sequencing.

===============

Observation 1 is a direct efficiency improvement because the time required for one summarization task fell substantially. Observation 2 shows that local time savings have not yet translated into higher organizational productivity or billable output. Observation 3 is explicitly a solution-cost problem caused by unnecessary API calls. Observation 4 introduces additional human correction time and therefore partially offsets the gross efficiency gain reported in Observation 1. Option D is the only answer that keeps these value dimensions distinct. Measuring only generation speed would overstate realized value because review effort, retry costs, and downstream output must also be included. A valid post-deployment assessment should calculate net cycle time, cost per accepted summary, correction rate, and resulting business output.

The correct general precedence is managed configuration, command-line arguments, local configuration, project configuration, and then user configuration.

Managed configuration has the highest authority because it contains centrally administered organizational and compliance controls that ordinary engineers must not be able to override. Command-line arguments provide temporary session-level overrides where the relevant setting permits them. Local settings apply to one user within a specific repository and take precedence over the shared project configuration. Project settings apply to every contributor using that repository and override general user preferences. User settings form the lowest tier because they provide personal defaults across projects and apply only when no higher-precedence source supplies a value.

Anthropic documents this order explicitly: managed, command line, local, project, and user. It also notes that permission rules may merge rather than behave as simple scalar overrides, and certain security-sensitive keys have specialized precedence behavior. Claude Code Configuration Scopes

The ordering allows personal customization without permitting it to defeat repository conventions or centrally mandated security requirements. Architects must still examine the merge behavior of the individual configuration property rather than assuming every array or permission rule is replaced wholesale.

Study Guide references/topics: Claude Code configuration; scope precedence; managed policies; local overrides; project settings; user defaults.

===============

Role-based access control directly supports HIPAA’s access-control and minimum-necessary principles. The retrieval and orchestration layers must verify the authenticated user’s role before protected health information enters the model context. Authorization should be applied to individual records, data sources, tools, and actions, with audit events recording the requesting identity, accessed resource, purpose, and result. Model instructions alone are not a security boundary.

Patient information must also remain within services and processing activities covered by the organization’s Business Associate Agreement. Anthropic states that PHI processing requires a HIPAA-ready organization and an accepted BAA, and that only specified eligible services and configurations are covered. Patient data must not be submitted through training, feedback, beta, third-party, or integration pathways that fall outside the applicable agreement. A BAA is not blanket authorization; architects must verify feature eligibility and disable inappropriate data-sharing mechanisms.

Reducing max_tokens, selecting a more capable model, and enabling streaming affect output length, quality, or latency. They do not establish authorization, contractual coverage, minimum-necessary access, or compliant PHI handling.

Study Guide references/topics: Anthropic Business Associate Agreement requirements; HIPAA-ready services; PHI access control; minimum necessary; eligible-service boundaries; auditability.

===============

Security and compliance reviewers must determine whether material threats have been identified, whether required controls address those threats, how remaining exposure will be accepted, and whether the decision can be demonstrated during an audit. Option C supplies exactly that evidence.

The threat model establishes protected assets, trust boundaries, adversaries, attack paths, and likely failure modes. Control mappings connect technical and procedural safeguards to organizational policies, regulatory requirements, and assurance frameworks. Residual-risk acceptance criteria define which risks may remain after mitigation, who has authority to accept them, and when further treatment is mandatory. Audit traceability connects requirements and decisions to implementation evidence, evaluations, approvals, logs, and operational monitoring.

Option A is designed primarily for product management. Option B addresses engineering planning and execution. Option D is appropriate for an executive sponsor who requires business justification and a concise risk summary but normally does not perform detailed control verification.

Audience adaptation should not alter the architectural decision itself. It changes the depth, terminology, evidence, and ordering used to communicate the decision. Security and compliance reviewers require verifiable control evidence rather than only schedule, implementation, or business-level summaries.

Study Guide references/topics: Audience-specific communication; threat modeling; compliance control mapping; residual-risk acceptance; audit evidence; architectural decision traceability.

===============