Mock Exam 03 · 答案册（Answer Key & Explanations）

配套 mock-03.md。每题全套格式：Best choice / Why / Why others are weaker / Tradeoffs / What would change the answer。原创教学题，非官方真题。技术原则出处以课程模块标注（M01–M13）。CCAR-P 七域权重 = 官方 Exam Guide（VERIFIED，截至 2026-08-30）。

快速答案表

自评（课程推断）：≥28/40（70%）达到进阶稳固线；<24 回看 M10–M13 与治理模块。

Part I · Integration

Q1. B

• Why: MCP 的核心价值：N 系统 × M 客户端的定制集成矩阵收敛为 N+M——每个系统一次受控暴露，5 个团队消费同一标准协议；安全审查集中到 server/gateway 层。
• Why others are weaker: A 放任 N×M 继续爆炸，安全口径不一致；C 单体 mega-agent 是单点故障+最大爆炸半径；D 一刀切禁用放弃全部价值。
• Tradeoffs: 需要平台团队维护 server 生命周期与治理；一次性迁移成本。
• What would change the answer: 若只有 1 个系统 × 1 个客户端，直接 API 集成可能更简单（MCP 的收益随 N、M 增长）。

考什么：何时用 MCP vs 直接集成（M06；CCAR-P Integration 核心）。

Q2. C

• Why: 结构感知分块（heading/clause 边界 + 标题链元数据 + 文档级上下文）直接修复「chunk 失去主语」的核心缺陷；clause 级精度可审计。
• Why others are weaker: A 更小窗口加剧主语丢失；B 整文档单块在 200 万文档规模不可行且 context rot；D 按句切碎语义更碎。
• Tradeoffs: 解析标题结构需要一次性工程投入；表格类内容需专门策略。
• What would change the answer: 语料若是无结构的自由文本（邮件），退而求其次用带重叠的固定窗口+上下文注入。

考什么：chunking 策略与 metadata（M07；CCAR-P Integration）。

Q3. D

• Why: 分层路由让精度-延迟权衡变成显式设计：深度研究走 rerank（8s SLO 内可容纳 300ms），快查走一阶段检索——两类用户各得其所。
• Why others are weaker: A 全量 rerank 为快查付无谓延迟与成本；B 全关牺牲法律场景质量；C 放弃检索微调 = 幻觉风险回归。
• Tradeoffs: 路由分类器本身要维护与评估；错误路由会送错层。
• What would change the answer: 若所有查询都是高价值深研（错误成本极高），全量 rerank 可辩护。

考什么：accuracy-latency tradeoff 的分层化（M07/M10）。

Q4. A

• Why: 可诊断性 = 结构化 trace（prompt 模板版本、工具调用、token、每步延迟/成本）+ PII 脱敏 + 按域指标——与公司遥测标准集成而非另起炉灶。
• Why others are weaker: B grep 不可扩展；C 全量原始 payload 入共享表格是合规事故；D 事后凭记忆不可能。
• Tradeoffs: 埋点有开发成本；采样率要在调试价值与存储/合规间平衡。
• What would change the answer: 无。

考什么：observability 集成选型（M12；CCAR-P Integration 点名监控选型）。

Q5. B

• Why: 数据驻留是接入路径决策：EU 区域的 Bedrock/Vertex 部署 + DPA + 数据流图，给法务一个可辩护故事；Claude 可用性经云厂商区域服务落地。
• Why others are weaker: A prompt 剥 PII 不是驻留控制（内容仍出境）；C 弃用 Claude 损失能力且自建栈超预算；D 违规。
• Tradeoffs: 区域部署可能滞后于直连 API 的最新特性；多了一条云依赖链。
• What would change the answer: 若合规进一步要求 Zero Data Retention 条款或特定认证（如政府云），路径选择要再收敛。

考什么：合规影响接入路径（M10/M11；CCAR-P Integration）。

Q6. D

• Why: 联邦注册表（owner/元数据强制）+ tool search / progressive discovery：目录可搜索、定义按需加载——治理与可发现性兼得，300→每次请求只载相关的几个。
• Why others are weaker: A 人工白名单 50 个在 300 规模不可持续且扼杀业务；B 全量加载正是病因；C 静默删除制造事故。
• Tradeoffs: 注册表元数据质量决定发现质量；搜索层增加一跳延迟。
• What would change the answer: 工具数缩到 ~20 且稳定时，直接全量加载更简单。

考什么：progressive discovery vs monolithic context（M06；CCAR-P Integration 点名）。

Q7. A

• Why: 按负载分流：季度 500k 走 Message Batches（约半价、24h 窗口 ≪ 3 天 SLA）；交互问答留实时 streaming API——各用各的最优解。
• Why others are weaker: B 全实时全价浪费一半预算；C Batches 不支持流式，交互工具会被破坏；D 外包丢掉已建能力。
• Tradeoffs: 两套调用路径要分别监控；Batches 结果落地要建管线。
• What would change the answer: 若季度任务 SLA 收紧到小时级，Batches 不再适用。

考什么：Batches 的成本-延迟定位（M03/M10）。

Q8. B

• Why: 版本化、schema 校验的交接契约（findings/evidence/scope/confidence/trace ID）经队列交换：两团队独立发布、格式演进不破坏、端到端可追溯。
• Why others are weaker: A 合并代码库耦合团队节奏；C 全量 transcript 转储正是现状病因；D 人工重打字不可扩展。
• Tradeoffs: 契约 schema 要治理（谁加字段、版本策略）；队列是新增基础设施。
• What would change the answer: 若两 agent 同属一个团队同仓发布，进程内结构化调用即可，无需队列。

考什么：agent 间集成契约设计（M06/M08；CCAR-P Integration 点名 agent-to-agent）。

Part II · Solution Design & Architecture

Q9. B

• Why: 步骤由法规固定 → 确定性 workflow 编排；LLM 只插在真正需要语言智能的两点（抽取、摘要），且各带 schema 输出与校验——可审计、延迟可预测、失败面最小。
• Why others are weaker: A 自主 agent 把监管流程的控制权交给模型（不可审计）；C multi-agent 辩论对固定流程是纯开销；D 丢掉自动化价值。
• Tradeoffs: workflow 变更要走发布流程；LLM 插入点仍是质量监控重点。
• What would change the answer: 若未来理赔含开放式调查子任务，可对该子任务局部引入 agent，其余保持 workflow。

考什么：workflow-first 原则（M08；CCAR-P Solution Design 核心）。

Q10. A

• Why: 四前提全满足（开放式、可并行、超窗口、高价值）——orchestrator-workers + 结构化笔记 + coordinator 合并引用是正解；15× token 经济学由六位数价值覆盖。
• Why others are weaker: B 1M 窗口装不下且 context rot；C 静态清单违背「研究中涌现线索」的本质；D 放弃 AI。
• Tradeoffs: 需要引用合并与去重机制；长时限任务的中间检查点设计。
• What would change the answer: 若任务缩到固定 20 份文件、单窗可容，chaining 即可。

考什么：multi-agent 四前提判断（M08）。

Q11. C

• Why: 合规规则落在确定性层：gateway/orchestration 内容检查 + 代码中的审批门——与模型输出无关地强制执行，且全链路审计日志。
• Why others are weaker: A system prompt 是软约束；B 内置安全不认识你的业务规则；D 用户举报是事后且不可靠。
• Tradeoffs: 内容检查器本身要维护（规则变更走代码）；有少量延迟开销。
• What would change the answer: 无——政策类强制永远不该依赖模型行为。

考什么：参考架构中的强制点位置（M10/M11）。

Q12. D

• Why: 面向 SLO 的工程组合：简单查询路由到快档+prompt caching（稳定前缀命中）、高频答案预计算、复杂查询分段/流式体验——每层带质量门。
• Why others are weaker: A 拿 SLO 不当约束；B 砍知识库伤质量；C 退化成脚本 bot。
• Tradeoffs: 路由错误会把复杂问题送进快通道（要留人工纠正回路）；缓存失效要管理。
• What would change the answer: 若复杂查询占比升到主导，投资重心转向复杂路径的延迟优化而非分流。

考什么：SLA/延迟驱动的架构设计（M10；CCAR-P Solution Design 点名业务价值对齐）。

Q13. A

• Why: 网关层按租户计量（tenant ID+model+tokens+cost 逐请求日志）、预算阈值告警、超限限流/排队，租户可见的仪表盘——归因、预算、防饥饿三合一。
• Why others are weaker: B 按席位平摊与用量脱钩；C 涨价不解决归因；D 季度表格无法实时防饥饿。
• Tradeoffs: 计量埋点与仪表盘建设成本；限流策略要与租户 SLA 协商。
• What would change the answer: 若只有 2-3 个租户，轻量级账单汇总可能够用。

考什么：多租户成本架构（M10）。

Q14. B

• Why: augmented LLM 形态：混合检索+引用、3 个聚焦工具、草稿走 structured output——行动面小而可验证，幻觉面（检索有据）与审计性都最优。
• Why others are weaker: A 40 工具漫游 = 选择准确率崩+爆炸半径大；C 数据库写权的自主 agent 不可审计；D 无工具无检索答不了订单状态。
• Tradeoffs: 行动面收窄后新需求要评估是否加工具（防工具蔓延）。
• What would change the answer: 若任务演化为开放式多步调查，再考虑 agent loop。

考什么：augmented LLM vs agent 的选型（M08；CCAR-P Solution Design 点名模式选型）。

Q15. B

• Why: pinned snapshot + 评估门 + 分阶段发布 + 快速回滚（重指旧 snapshot）——行为可预测、升级有证据、回退是配置操作。
• Why others are weaker: A 移动 alias 恰是本次事故的原因；C 永不升级堆积技术债；D 运行时随手选模型不可治理。
• Tradeoffs: 错过自动改进，需要主动升级节奏（定期评估新 snapshot）。
• What would change the answer: 无——生产版本管理的标准答案。

考什么：模型版本管理策略（M02/M10/M12）。

Part III · Evaluation, Testing & Optimization

Q16. D

• Why: 从历史工单采样建 golden dataset + 分级 rubric（任务成功/groundedness/安全）→ CI 回归门 → 可测量的发布门槛——上线前后同一套 harness。
• Why others are weaker: A 用户当小白鼠（声誉与合规风险）；B 10 次手工对话无统计力；C 截图不是评估。
• Tradeoffs: 数据标注有成本；rubric 要定期校准。
• What would change the answer: 无。

考什么：评估程序设计（M12；CCAR-P Evaluation 核心）。

Q17. A

• Why: 稳定哈希分流（同用户同变体，体验不抖）+ guardrail 指标（升级率/延迟/成本）带告警 + 渐进放量 + 自动回滚——实验有效性与安全兼得。
• Why others are weaker: B 逐请求随机污染用户体验且指标不可分；C 全量切换无对照；D 主观偏好不是生产证据。
• Tradeoffs: 实验周期拉长（要攒够样本）；哈希分流要防止与其它实验纠缠。
• What would change the answer: 若变更纯后端且无用户感知差异，逐请求分流也可接受。

考什么：A/B 测试工程（M12）。

Q18. B

• Why: 先分析 9 题回退（失败模式/题目分布：长上下文抽取）→ 可修（prompt/schema）则修复重评 → 达标后 1%→25%→100% 灰度 + 回滚预案；不达标暂缓——6 个新通过的价值要保留但不以回归为代价。
• Why others are weaker: A 「新=更好」是信仰不是工程；C 79≈82 忽略了回归聚类的风险；D 一年禁令是惰性。
• Tradeoff: 两周窗口内要先花几天做失败分析（值得）。
• What would change the answer: 若 9 题回退属不可修的模型能力差异且落在核心场景，结论直接是暂缓。

考什么：升级回归的分诊流程（M12/M02）。

Q19. D

• Why: cascade 的第一 KPI 是升级率（升级到强模型的比例）——它同时决定平均成本与质量；成本涨 30% 先查升级率为何升（阈值漂移/流量变难/工具失败）。
• Why others are weaker: A 总请求量不解释成本结构；B 单价不是你能控的变量；C 砍强模型伤复杂查询质量。
• Tradeoff: 升级率有目标区间，过低可能意味着该升不升（质量受损）。
• What would change the answer: 无。

考什么：cascade 监控（M10/M12）。

Q20. D

• Why: 指标要联合解读：幻觉率、弃答率、任务成功率三者的权衡带——「全拒答」能把幻觉刷成 0 但产品已死。
• Why others are weaker: A 单指标可被 gaming；B 禁止拒答把不确定性强转幻觉；C 只看完成率对幻觉盲。
• Tradeoff: 目标带设定要与产品风险偏好对齐（监管场景幻觉容忍更低）。
• What would change the answer: 无。

考什么：幻觉/模型错配诊断（M12；CCAR-P Evaluation 点名）。

Q21. A

• Why: trace 级结构化捕获：每个请求记录检索到的 chunk ID、工具调用、prompt 模板版本、模型、延迟、成本——PII 脱敏、采样、按 trace ID 可查——间歇性失败才能事后定位。
• Why others are weaker: B 截图猜测；C 状态码无内容；D 手工复现对间歇问题无效。
• Tradeoff: 存储与脱敏管线成本；采样会漏掉部分事件。
• What would change the answer: 无。

考什么：可观测性管线（M12）。

Part IV · Governance, Safety & Risk Management

Q22. B

• Why: 管线：受批研究的 RAG + 引用 → 顾问在门控 UI 审批 → 发送；审计日志记录草稿/来源/审批/版本——模型永不终审，监管三条全满足。
• Why others are weaker: A 直发客户违规；C 微调进参数 = 不可溯源不可更新；D 全人工放弃效率价值。
• Tradeoff: 顾问审批是吞吐瓶颈（要监控审批时长）。
• What would change the answer: 无——监管场景 HITL 是硬约束。

考什么：HITL 验证 + 审计链（M11；CCAR-P Governance 核心）。

Q23. C

• Why: 三层处理：入口脱敏 PII、内容级日志进独立加密存储（最小权限+30 天保留）、运营指标留在通用存储——调试价值保留，暴露面收敛。
• Why others are weaker: A 全删日志丢可诊断性；B 换账号不解决权限过宽；D README 不是控制。
• Tradeoff: 脱敏规则维护成本；独立存储的访问流程更重。
• What would change the answer: 无。

考什么：PII 日志治理（M11/M12；CCAR-P Governance 点名合规）。

Q24. D

• Why: defense-in-depth：输入侧把检索内容当数据筛查 + 工具最小权限 + egress 白名单 + 外发人工审批门——任何单层失效都有下一层兜底。
• Why others are weaker: A 教育用户不是技术控制；B system prompt 一行字是被官方点名的伪防线；C 砍能力弃功能。
• Tradeoff: 层层叠加增加延迟与复杂度；审批门有疲劳风险（保留给真正高影响动作）。
• What would change the answer: 无——间接注入没有单点解。

考什么：间接注入纵深防御（M11；CCAR-P Governance）。

Q25. C

• Why: HIPAA 三件套：BAA 覆盖的服务承载 PHI 流量、字段级去标识/最小化、每次 PHI 访问可归因到用户并审计——合规与功能并存。
• Why others are weaker: A 无 BAA 的消费级产品直接违规；B 只删名字不删 ID+诊断组合，仍可重识别；D 培训不是控制。
• Tradeoff: BAA 路径的模型/区域选择受限；去标识管线有工程成本。
• What would change the answer: 无。

考什么：健康数据合规架构（M11；CCAR-P Governance 点名 HIPAA）。

Q26. B

• Why: 拆解 god-tool：只读 SQL 限定批准的 schema/视图 + 独立的审批门写路径——万能工具的爆炸半径收窄到明确范围；原本 23 个工具的隔离因它形同虚设，现在整体恢复意义。
• Why others are weaker: A prompt 不是权限；C 全禁伤分析师生产力；D 扩散风险方向反了。
• Tradeoff: 分析师的临时查询要预先建视图（平台响应成本）。
• What would change the answer: 无。

考什么：最小权限与 blast radius（M11；CCAR-P Governance）。

Q27. C

• Why: 多租户隔离在应用与数据层强制：范围凭证、检索租户 pre-filter、按租户限定工具域；prompt 是指导不是授权——并用跨租户攻击用例测试。
• Why others are weaker: A/B 把授权交给模型是全课程第一反模式；D 混淆名字不是隔离。
• Tradeoff: 每租户凭证/filter 的运维复杂度。
• What would change the answer: 无。

考什么：LLM instruction ≠ application enforcement 的多租户版（M07/M11）。

Part V · Stakeholder Communication & Lifecycle Management

Q28. D

• Why: ADR（架构决策记录）：背景、备选、决策、tradeoff、显式重审触发条件（「若理赔复杂度开放化，重评 multi-agent」）——六个月后决策可复盘、新人可上手。
• Why others are weaker: A 记忆会流失；B 一行标题无信息；C 聊天记录不可检索不可信。
• Tradeoff: ADR 维护纪律成本。
• What would change the answer: 无——「无 tradeoff 记录的决策视为未完成」。

考什么：决策文档化（M13；CCAR-P Stakeholder 点名决策与 trade-off 沟通）。

Q29. B

• Why: 面向高管的语言：业务 KPI（拦截率、每票成本、CSAT 变化）+ 风险与缓解 + 需要他们做的 2–3 个决策——技术深度放附录。
• Why others are weaker: A attention maps 是工程师内部语言；C token 数不是价值语言；D 不更新丢信任。
• Tradeoff: 要维护业务指标与工程指标的映射关系。
• What would change the answer: 若听众是技术委员会，才上架构细节。

考什么：结构化干系人沟通（M13；CCAR-P Stakeholder 点名）。

Q30. B

• Why: 周循环：反馈分类分诊 → 高频失败案例进 golden dataset → 修 top 类别 → eval 验证 → 向干系人发布前后对比——同一失败不再月月重演。
• Why others are weaker: A 删收件箱掩耳盗铃；C 自动道歉不修因；D 年度批量修 = 用户流失一年。
• Tradeoff: 每周固定投入（值得）。
• What would change the answer: 无。

考什么：反馈回路（M12/M13；CCAR-P Stakeholder 点名反馈回路）。

Q31. D

• Why: 事故沟通双段式：进行中给干系人及时更新（影响/缓解/ETA），事后 blameless postmortem（时间线、根因、带 owner 与日期的 action items，含降级设计的复盘）。
• Why others are weaker: A 假装没事摧毁信任；B 原始日志泄露内部信息；C 公开 blame 导致未来瞒报。
• Tradeoff: postmortem 文化需要管理层背书。
• What would change the answer: 无。

考什么：事故沟通与生命周期管理（M10/M13）。

Q32. C

• Why: 90 天迁移跑道：盘点依赖应用 → 每应用在新 snapshot 上建 eval 基线 → 修差距 → 到期前分阶段切换 → 带日期的干系人沟通计划——没有硬切换事故。
• Why others are weaker: A 拖到故障是最大风险；B 立即切 alias 重演 Q15 事故；D 个人豁免不解决系统性问题。
• Tradeoff: 提前占用工程资源（远比事故便宜）。
• What would change the answer: 无。

考什么：模型生命周期管理（M02/M10；CCAR-P Stakeholder 点名 lifecycle）。

Part VI · Claude Models, Prompting & Context Engineering

Q33. C

• Why: 按成本/延迟/能力三轴 × 任务画像匹配：500 万/天短分类→快档；500/天法律深析→旗舰；5 万/天中难草稿→中档+caching——每档用 per-workload eval 验证。
• Why others are weaker: A 全旗舰预算爆；B 全便宜质量崩再救火更贵；D 周度轮换不可测试。
• Tradeoff: 多档位意味着更多组合要回归测试。
• What would change the answer: 单一任务画像才考虑单一模型。

考什么：模型选型 trade-off（M02/M10；CCAR-P Models 域点名模型选型）。

Q34. B

• Why: 模块化 prompt 架构：共享安全/身份/格式模块做稳定可缓存前缀（版本化），团队自有尾部段落；变更走共享 eval harness；Claude Code 侧把可复用工作流打包 Skills。
• Why others are weaker: A 禁共享=漂移永久化；C 平台团队单点瓶颈；D 随机化毁掉缓存与质量。
• Tradeoff: 模块接口设计（哪些进共享层）要治理。
• What would change the answer: 无。

考什么：prompt 复用（caching/modular/Skills；CCAR-P Models 域点名）。

Q35. D

• Why: 混合检索（向量+关键词，补条款号/区域码这类精确 token）+ 版本有效性元数据过滤（季度作废不泄漏）+ clause 级分块带标题链 + 逐主张引用——四个约束逐一落地。
• Why others are weaker: A 全量塞入无引用且旧版泄漏（只靠缓存省钱不解决时效）；B 无版本过滤答出旧政策；C 参数知识不知你的政策且幻觉。
• Tradeoff: 检索管线建设与季度重索引成本。
• What would change the answer: 若手册极小（几页）且更新慢，全量+缓存可接受。

考什么：上下文工程与检索决策（M07；CCAR-P Models 域点名上下文与 token 优化）。

Q36. D

• Why: 按成本结构逐项打：caching 吃掉 60% 的稳定前缀重复、输出长度纪律（schema/简洁格式）压 25% 冗长输出、升级阈值调优+定点修复 降 15% 强档升级——每项有 eval 保质量。
• Why others are weaker: A 砍知识库伤准确率；B 转嫁客户不解决浪费；C 单模型伤复杂任务。
• Tradeoff: 三个杠杆都要测量验证，不能拍脑袋。
• What would change the answer: 无。

考什么：token 成本优化组合拳（M03/M10；CCAR-P Models 域点名 token 优化）。

Q37. B

• Why: 先审计映射（owner/用途/已知行为）→ 抽公共安全核心为版本化模块 → 带 per-app eval 基线分波迁移 → 公布时间表淘汰分叉——两周内安全更新可验证地到达所有应用。
• Why others are weaker: A 全局 find-replace 同时上线是盲改；C 自生自灭拖一年；D 隔夜政变无回滚。
• Tradeoff: 审计阶段耗时（但不可跳过）。
• What would change the answer: 若仅 2-3 个应用且 owner 明确，可简化为直接合并。

考什么：prompt 标准化与迁移治理（M05/M10）。

Part VII · Developer Productivity & Operational Enablement

Q38. B

• Why: managed settings（deny+hooks）作组织底线 + 共享 Skills/subagents 库让模式复用而非重复发明 + 培训引导——治理与生产力兼得，采纳复利。
• Why others are weaker: A 全员 bypass 是事故预备；C 一队试点无复利且其余 199 人用不上；D 观望丢先发学习曲线。
• Tradeoff: 平台团队要持续维护 skills 库质量。
• What would change the answer: 无。

考什么：Claude Code 企业落地治理（M09；CCAR-P DevProd 核心）。

Q39. C

• Why: headless claude -p + 收紧权限（只读工具/deny/hooks）+ 机读输出（JSON）+ 结果贴 PR 评论 + eval 调过的阈值控噪——无人值守、可集成、可信。
• Why others are weaker: A 人盯 CI 违背自动化初衷；B bypass+全写权是最危险的 CI 配置；D 手工执行等于没有。
• Tradeoff: 阈值调优期有误报；只读权限限制能做的检查类型。
• What would change the answer: 无。

考什么：headless CI 集成（M09；CCAR-P DevProd 点名环境配置）。

Q40. D

• Why: runbook 打包为版本化 Skills（参数化命令、生产危险步骤有权限提示/hooks 门、全程审计日志）——on-call 跟着 skill 走而不是翻过期 wiki，MTTR 下降可测量。
• Why others are weaker: A 更多 wiki 加剧陈旧；B 死记不扩展；C 只 senior 值班成本高且无韧性。
• Tradeoff: skills 维护纪律（runbook 月更要落到 skill 版本）。
• What would change the answer: 无。

考什么：运维赋能（M09/M10；CCAR-P DevProd 点名运维支持）。

（Mock 03 答案册完） · 回做：mock-03.md · 收口卷：mock-04.md