Learn > Claude > Claude Certified Architect — Foundations (CCA-F)

Claude Certified Architect — Foundations (CCA-F)

Tổng quan cấu trúc đề thi, 12 quy luật phán đoán kiến trúc và đề thi thử các câu hỏi tình huống sát đề thật.

  • Kỳ thi CCA Foundations (CCA-F) kiểm tra năng lực ra quyết định và đánh đổi kiến trúc (tradeoffs) của Solution Architect khi xây dựng giải pháp thực tế với Claude.
  • Cốt lõi của việc ôn tập nằm ở 12 quy luật phán đoán kiến trúc giúp loại bỏ các phương án nhiễu (distractors) được thiết kế tinh vi trong đề thi.
  • Tích hợp 4 hệ thống mẫu thực tế (Customer Support, Developer Workflow, Structured Extraction, Multi-Agent Research) kết nối toàn diện kiến thức 5 domain.

TL;DR — Kỳ thi Claude Certified Architect – Foundations (CCA-F) của Anthropic kiểm tra phán đoán kiến trúc thực tế chứ không hỏi lý thuyết suông. Để ôn thi hiệu quả và bảo đảm điểm số tối ưu, tôi đúc kết 12 quy luật phán đoán kiến trúc cốt lõi, 4 hệ thống mẫu thực tế và chia nhỏ nội dung ôn tập thành 5 Domain chuyên biệt giúp tăng tốc độ tải trang.


1. Cấu trúc và Scenarios của đề thi

Đề thi CCA-F gồm các câu hỏi trắc nghiệm dựa trên các tình huống sản xuất thực tế. Trong quá trình thi, hệ thống sẽ chọn ngẫu nhiên 4 trong số 6 scenario dưới đây làm khung bối cảnh cho các câu hỏi:

  • Scenario 1: Customer Support Resolution Agent (Agent hỗ trợ khách hàng bằng Agent SDK, gọi các công cụ MCP để truy vấn đơn hàng, khách hàng, xử lý hoàn tiền hoặc chuyển lên người thực).
  • Scenario 2: Code Generation với Claude Code (Ứng dụng Claude Code để refactor, debug, viết tài liệu và kiểm soát workflow bằng Plan mode vs Direct execution).
  • Scenario 3: Multi-Agent Research System (Hệ thống điều phối nhiều agent: Coordinator phân rã nhiệm vụ và ủy thác cho các subagent tìm kiếm, phân tích và tổng hợp).
  • Scenario 4: Developer Productivity với Claude (Sử dụng các built-in tools như Read, Write, Bash, Grep, Glob để phân tích và tối ưu hóa hệ thống legacy lạ).
  • Scenario 5: Claude Code cho Continuous Integration (Tích hợp Claude Code vào CI/CD pipeline để review code tự động, giảm thiểu tỷ lệ báo động giả - false positive).
  • Scenario 6: Structured Data Extraction (Trích xuất thông tin từ tài liệu thô, validate bằng JSON Schema và tối ưu hóa quy trình kiểm duyệt thủ công của con người).

2. 12 Quy luật Phán đoán Kiến trúc (Architect's Judgement Rules)

Dưới đây là 12 nguyên tắc đinh để định hướng chọn đáp án đúng, giúp loại bỏ các phương án nhiễu (distractors) thường gặp:

  1. Tất định > Xác suất: Với các quy tắc kinh doanh bắt buộc (xác minh danh tính trước khi hoàn tiền, chặn hoàn tiền > $500), luôn sử dụng hooks lập trình (PreToolUse/PostToolUse) của Agent SDK. Không bao giờ tin cậy hoàn toàn vào prompt hay few-shot vì chúng chỉ mang tính xác suất.
  2. Sửa nguyên nhân gốc bằng cách rẻ nhất trước: Nếu agent chọn sai tool do mô tả sơ sài, giải pháp đầu tiên là viết lại tool description (thêm ví dụ, ranh giới rõ ràng). Đừng vội vàng over-engineer bằng cách thêm layer phân loại (classifier) hay gộp tool.
  3. Tối ưu prompt trước khi thêm hạ tầng: Để cải thiện hiệu chuẩn (calibration) định tuyến, ưu tiên thêm tiêu chí rõ ràng và few-shot vào prompt trước khi huấn luyện mô hình phân loại (ML classifier) hay phân tích cảm xúc khách hàng.
  4. Phạm vi chia sẻ quyết định vị trí cấu hình: Công cụ, lệnh hay chuẩn code dùng chung cho cả team phải được commit vào repository (đặt tại .claude/commands/, .claude/rules/ hoặc .mcp.json). Những gì dùng cá nhân thì đặt ở thư mục home (~/.claude/...).
  5. Tác vụ phức tạp, ảnh hưởng rộng → Plan mode ngay: Nếu công việc đụng tới hàng chục file và đòi hỏi quyết định cấu trúc/ranh giới microservice, hãy dùng Plan mode để khảo sát và thiết kế an toàn trước khi chạy thực tế.
  6. Quy chuẩn theo loại file rải rác → rules + glob pattern: Để áp đặt quy tắc cho file test nằm rải rác khắp nơi, dùng file cấu hình trong .claude/rules/ kết hợp glob pattern (VD: **/*.test.tsx). Tránh dùng CLAUDE.md trong từng thư mục con vì khó bảo trì.
  7. Lỗi thiếu hụt nằm ở khâu phân rã nhiệm vụ: Nếu các subagent thực thi hoàn hảo nhưng kết quả tổng hợp vẫn bị thiếu mảng thông tin lớn, lỗi nằm ở khâu phân rã task quá hẹp của coordinator, đừng đổ lỗi cho các subagent downstream.
  8. Lỗi phải mang đầy đủ ngữ cảnh (Contextual Error): Khi tool hoặc subagent thất bại, nó phải trả về thông tin chi tiết (loại lỗi, query đã thử, kết quả một phần và hướng xử lý). Nuốt lỗi hoặc huỷ bỏ toàn bộ luồng đều là anti-patterns.
  9. Quyền hạn tối thiểu & Tối ưu cho số đông: Cấp cho agent công cụ vừa đủ cho 85% tác vụ đơn giản thường gặp (như verify fact nhanh) để giảm tải latency cho coordinator. 15% ca phức tạp mới route ngược về coordinator điều phối.
  10. Cảnh giác với tính năng không tồn tại: Đề thi của Anthropic rất hay cài bẫy bằng các flag, biến môi trường hay file cấu hình tự bịa (VD: --batch flag cho CLI, CLAUDE_HEADLESS env, hay .claude/config.json).
  11. Khớp API với yêu cầu về độ trễ (Latency SLA): Workflow chặn (developer đang chờ code merge) bắt buộc dùng API đồng bộ real-time. Workflow không chặn, chạy định kỳ (báo cáo nợ kỹ thuật qua đêm) hãy dùng Message Batches API để tiết kiệm 50% chi phí.
  12. Attention là tài nguyên hữu hạn: Để xử lý đống code PR lớn gồm nhiều file, hãy chia thành các pass tập trung (pass 1: file-by-file độc lập; pass 2: integration chéo). Việc tăng context window hay đổi model lớn hơn không giải quyết được chất lượng attention.

3. Apply thực tế: 4 kiến trúc hệ thống mẫu end-to-end

Để mường tượng trực quan cách vận hành của hệ thống trong thực tế và cách giải quyết các bài toán tradeoffs, tôi thiết kế 4 hệ thống mẫu đại diện cho các scenario chính:

Hệ 1: Agent CSKH cho shop e-commerce (Scenario 1)

Khách hàng (Chat Widget)


┌─────────────────────────────────────────────────────┐
│  AGENT (Claude Agent SDK)                            │
│  • System prompt: tiêu chí escalation + few-shot     │
│  • [CASE FACTS] block: được giữ cố định mỗi lượt      │
│  • Agentic loop: chạy theo stop_reason               │
│                                                      │
│  Hooks:                                              │
│  • PreToolUse  → Chặn process_refund khi chưa có     │
│    customer ID xác minh; chặn refund > $500          │
│  • PostToolUse → Chuẩn hóa timestamp/status code     │
└──────────────┬──────────────────────────────────────┘
               │ MCP Giao tiếp (.mcp.json)

    get_customer / lookup_order / process_refund / escalate_to_human
  • Vòng lặp Agentic Loop: Agent nhận input, gọi Messages API và kiểm tra stop_reason. Nếu là "tool_use", agent chạy tool tương ứng (VD: lookup_order), lấy kết quả đưa ngược vào context để gọi lượt kế tiếp. Nếu là "end_turn", agent trả lời khách và thoát vòng lặp.
  • Hoạt động của PreToolUse Hook: Nếu khách hàng yêu cầu hoàn $650, hook lập trình PreToolUse sẽ lập tức chặn cuộc gọi process_refund (vì số tiền vượt ngưỡng tự động $500), đồng thời ép agent gọi tool escalate_to_human.
  • Escalation & Handoff: Khi escalate, agent tự động xuất một Handoff Summary có cấu trúc gửi cho nhân viên trực hỗ trợ (người này không đọc transcript):
    [HANDOFF SUMMARY]
    - Customer ID: C-88213 (Đã xác minh qua get_customer)
    - Yêu cầu: Hoàn tiền đơn hàng giao thiếu #A-1023
    - Số tiền: $650.00 (Vượt ngưỡng tự động của Agent)
    - Đề xuất: Nhân viên duyệt chi bằng tay sau khi kiểm kho.
    
  • PostToolUse & Case Facts: Nếu lookup_order trả về 40+ trường dữ liệu, PostToolUse hook sẽ cắt gọn chỉ giữ lại 5 trường liên quan (order_id, status, items, total, date) và ghi vào block [CASE FACTS] nằm ở đầu prompt để tránh bị trôi khi tóm tắt chat.

Hệ 2: Claude Code cho team dev + CI review (Scenario 2, 4, 5)

Thư mục dự án (Repo Git)
├─ CLAUDE.md                      ← Quy chuẩn code chung, cách chạy test, @import rules con
├─ .claude/
│  ├─ rules/
│  │  ├─ testing.md               ← Rule viết test functional (paths: ["**/*.test.*"])
│  │  └─ api-conventions.md       ← Rule thiết kế API (paths: ["src/api/**/*"])
│  ├─ commands/
│  │  └─ review                   ← Custom command /review chạy checklist của team
│  └─ skills/
│     └─ analyze-module           ← Custom skill cá nhân, context: fork (chạy cô lập)
└─ .mcp.json                      ← Khai báo server MCP dùng chung (Jira/GitHub)
  • Tải rule có điều kiện (Path-scoped rules): Khi dev sửa file src/api/user.ts, chỉ có api-conventions.md được nạp vào context. Khi viết file test, testing.md được nạp. Thiết lập này giúp tiết kiệm tối đa token và không làm loãng sự tập trung của mô hình.
  • Explore Subagent trong Plan Mode: Khi dev chạy task di chuyển thư viện lớn (VD: moment sang date-fns trên 50 files), Claude Code tự động spawn một Explore Subagent chạy ngầm để đọc codebase và lên kế hoạch (Plan). Kết quả khảo sát dài dòng được subagent nén lại thành một bản tóm tắt kiến trúc gửi cho coordinator, giữ cho context hội thoại chính luôn sạch sẽ.
  • Tích hợp CI/CD tự động: Pipeline chạy lệnh non-interactive để review PR:
    claude -p "/review" --output-format json --json-schema review-schema.json
    
    Instance này chạy độc lập hoàn toàn với instance dev dùng để viết code, đảm bảo tính khách quan tối đa khi review (không bị thiên kiến xác nhận - confirmation bias).

Hệ 3: Pipeline trích xuất 5.000 hoá đơn mỗi đêm (Scenario 6)

23:00  Gom 5.000 hoá đơn PDF ──→ Messages Batches API (custom_id = mã file)
                                      │ (Tiết kiệm 50% chi phí, xử lý trong 24h)

07:00  Nhận kết quả trích xuất ──→ Validate bằng Pydantic/JSON Schema

             ├─ Thành công ──→ So sánh Confidence của từng trường dữ liệu
             │                     ├─ Điểm tự tin cao  ──→ Ghi thẳng vào cơ sở dữ liệu
             │                     └─ Điểm tự tin thấp ──→ Đẩy vào hàng đợi kiểm duyệt thủ công

             └─ Thất bại ──→ Phân loại lỗi
                   ├─ Lỗi format/cấu trúc ──→ Gửi lại (Retry) kèm log lỗi chi tiết
                   └─ Lỗi thiếu thông tin ──→ Ghi nhận missing, chuyển sang duyệt thủ công
  • Sử dụng Schema Nullable chống ảo tưởng: Trong JSON Schema định nghĩa công cụ trích xuất, các trường không bắt buộc (VD: due_date) được khai báo kiểu ["string", "null"] và mô tả "để null nếu tài liệu không ghi, không được đoán". Điều này giúp Claude trả về null thay vì tự bịa ra một ngày ngẫu nhiên để thỏa mãn schema.
  • Quy trình Validation-Retry: Nếu kết quả trích xuất bị lệch số học (VD: tổng tiền các mặt hàng không bằng tổng tiền thanh toán), hệ thống gửi lại request:
    [FOLLOW-UP REQUEST]
    Tài liệu gốc: [Nội dung hóa đơn]
    Bản trích xuất lỗi: {"items": [{"price": 10}, {"price": 20}], "total": 40}
    Lỗi phát hiện: Tổng giá trị items (30) không khớp với trường total (40).
    Hãy kiểm tra lại và thực hiện trích xuất chính xác.
    
  • Kiểm duyệt dựa trên Confidence: Hệ thống lấy mẫu ngẫu nhiên phân tầng (stratified random sampling) từ nhóm dữ liệu tự động ghi (high-confidence) để kiểm định chất lượng định kỳ, phát hiện sớm các lỗi trôi dạt (concept drift).

Hệ 4: Hệ nghiên cứu multi-agent ra báo cáo có trích dẫn (Scenario 3)

                        ┌──────────────────────┐
    Yêu cầu nghiên cứu  │     COORDINATOR      │ (allowedTools chứa "Task")
   ────────────────────→│  Phân rã subtasks    │
                        │  Gom & Fact-check    │
                        └──────────┬───────────┘
                                   │ Spawning song song (nhiều Task call)
                 ┌─────────────────┼──────────────────┐
                 ▼                 ▼                  ▼
          [Search Agent]    [Search Agent]     [Analysis Agent]
             (Mảng nhạc)       (Mảng phim)       (Đọc PDF nguồn)
                 └─────────────────┬──────────────────┘
                                   │ Trả dữ liệu có cấu trúc:
                                   │ { claim, evidence, source_url }

                        ┌──────────────────────┐
                        │   SYNTHESIS AGENT    │ (Verify claims qua
                        │   Tổng hợp báo cáo   │  verify_fact tool chuyên biệt)
                        └──────────────────────┘
  • Orchestration & Parallel Spawning: Coordinator nhận đề bài, chia thành các nhánh tìm kiếm song song. Nó phát ra 3 lệnh gọi tool Task cùng một lúc trong một lượt API để spawn 3 subagent chạy song song, giảm 60% thời gian phản hồi (latency).
  • Memory Isolation: Mỗi subagent được cấp một system prompt riêng và nhận thông tin đầu vào tường minh. Coordinator không chia sẻ lịch sử hội thoại gốc của mình để tránh làm nhiễu ngữ cảnh làm việc của subagent.
  • Fact-Checking và Provenance: Subagent trả dữ liệu về theo định dạng cấu trúc nghiêm ngặt để giữ nguồn gốc (provenance):
    {
      "claim": "Thị trường streaming nhạc tăng trưởng 12% năm 2025",
      "evidence": "Doanh thu nhạc số đạt 18 tỷ USD, tăng 12% so với năm trước...",
      "source_url": "https://musicreports.com/2025",
      "retrieved_date": "2026-07-10"
    }
    
    Synthesis Agent sử dụng một tool có phạm vi hẹp (verify_fact) để tự tra cứu nhanh các thông số đơn giản mà không cần route ngược qua nhiều lượt với Coordinator.
  • Xử lý mâu thuẫn dữ liệu: Nếu nguồn A báo tăng 12% nhưng nguồn B báo tăng 15%, Synthesis Agent bắt buộc phải ghi nhận cả hai con số kèm theo nguồn và ngày xuất bản trong báo cáo cuối cùng, không được phép tự tính trung bình cộng hoặc tự ý bỏ một nguồn.

4. Lộ trình ôn tập chi tiết theo 5 Domain

Chi tiết nội dung và các ghi chú thực chiến cho từng phần kiến thức của kỳ thi nằm ở các liên kết dưới đây:


Từ khoá cần thuộc

🔴 Core: Agentic loop · Tool description · Programmatic hooks · Plan mode · 🟡 Important: Scoped tools · custom_id (Batch API) · Structured error propagation · glob path rules · 🟢 Good-to-know: Lost-in-the-middle · Confidence calibration · Stratified sampling · Provenance mappings


Muốn tự kiểm tra? Làm đề thi thử ở tab "Đề thi thử".

Câu hỏi thường gặp

Kỳ thi Claude Certified Architect — Foundations (CCA-F) chấm điểm thế nào?
Kỳ thi gồm các câu hỏi trắc nghiệm tình huống, chấm điểm theo thang từ 100 đến 1.000. Thí sinh cần đạt tối thiểu 720 điểm để được công nhận Đậu (Pass). Không bị trừ điểm khi chọn sai nên hãy điền đủ tất cả đáp án.
Khác biệt lớn nhất giữa kỳ thi CCA-F và các khóa học Anthropic Academy là gì?
Các khóa học Anthropic Academy cấp Course Certificate xác nhận việc hoàn thành nội dung học tập. CCA-F là kỳ thi chứng chỉ nghề nghiệp chính thức (proctored exam), đánh giá năng lực thực tế về phán đoán thiết kế hệ thống, MCP, CI/CD và quản lý rủi ro/độ tin cậy trong môi trường production.
Đề thi sử dụng các scenario bối cảnh nào?
Đề thi lựa chọn ngẫu nhiên 4 trong 6 scenario bối cảnh sản xuất: (1) Agent CSKH hỗ trợ e-commerce, (2) Lập trình với Claude Code, (3) Hệ thống nghiên cứu multi-agent, (4) Công cụ tăng năng suất cho dev, (5) Claude Code chạy trong pipeline CI/CD, và (6) Trích xuất dữ liệu hóa đơn có cấu trúc.

Đề thi thử (120 câu)

Đề thi thử tự biên soạn, bám sát đề thi chứng chỉ thật — trích 20 câu đầu dưới đây. Bản tương tác — chấm điểm, đáp án & giải thích từng câu — nằm ở tab “Đề thi thử” trên trang.

  1. Agentic Architecture Production data shows that in 12% of cases, your agent skips get_customer entirely and calls lookup_order using only the customer's stated name, occasionally leading to misidentified accounts and incorrect refunds. What change would most effectively address this reliability issue?

    • A. Add a programmatic prerequisite that blocks lookup_order and process_refund calls until get_customer has returned a verified customer ID.
    • B. Enhance the system prompt to state that customer verification via get_customer is mandatory before any order operations.
    • C. Add few-shot examples showing the agent always calling get_customer first, even when customers volunteer order details.
    • D. Implement a routing classifier that analyzes each request and enables only the subset of tools appropriate for that request type.
  2. Agentic Architecture Your system integrates multiple backend APIs that return timestamps in different formats (Unix epochs, ISO 8601 strings, and custom database formats). You want the agent to receive clean, uniform dates without wasting its context window on parsing logic. Where should you implement this normalization?

    • A. Inside the system prompt, instructing the model to normalize all timestamps before reasoning.
    • B. Inside a PostToolUse hook of the Agent SDK, intercepting the tool output to format the data before it is appended to the message history.
    • C. By adding few-shot examples showing the agent converting various formats to ISO 8601.
    • D. By setting tool_choice to force the agent to call a custom DateFormatter tool after every API request.
  3. Agentic Architecture In a customer support agent, a developer hard-coded a fixed tool sequence: the loop always calls get_customer, then lookup_order, then process_refund on every request. This misbehaves on requests that need none of those steps (e.g., a simple address change). What is the most appropriate redesign?

    • A. Remove the hard-coded sequence and let the model choose the next tool each iteration based on the evolving conversation context, feeding tool results back so it can reason about the next action.
    • B. Expand the decision tree with additional conditional branches to cover address changes, billing questions, and every other request type.
    • C. Deploy a separate intent-classification model that maps each incoming request to one of several predefined tool sequences before the agent runs.
    • D. Switch to a larger model so the fixed tool sequence produces better results on edge-case requests.
  4. Agentic Architecture In your multi-agent research pipeline, the synthesis agent produces reports whose claims can no longer be traced back to their sources because source URLs and publication dates are lost when the web search agent's output is handed off. How should you pass context to preserve attribution?

    • A. Pass each finding as structured data that separates the claim/content from its metadata (source URL, document name, publication date) so the synthesis agent preserves attribution through synthesis.
    • B. Concatenate all raw search result text into a single plaintext blob and let the synthesis agent re-derive the sources itself.
    • C. Enable context inheritance so the synthesis agent automatically receives the web search agent's full history including sources.
    • D. Give the synthesis agent a larger context window so more of the original source text fits alongside the claims.
  5. Agentic Architecture You built a codebase-exploration agent with the Claude Agent SDK. To stop the agentic loop you set a hard limit of 8 iterations as the primary termination mechanism. Complex investigations now get cut off before finishing, while trivial ones still run all 8 rounds. What is the correct way to control termination?

    • A. Raise the hard iteration cap to 50 so complex investigations have room to finish.
    • B. Parse the assistant's text each round and stop the loop once it contains a phrase such as 'investigation complete'.
    • C. Drive termination from stop_reason — continue while it is 'tool_use' and stop when it is 'end_turn' — keeping an iteration cap only as a secondary safety backstop.
    • D. Stop the loop as soon as a response contains any assistant text content alongside tool calls.
  6. Agentic Architecture To reduce latency, a developer wired the subagents in your research system to call one another directly instead of returning to the coordinator between steps. Now error handling is inconsistent and it is hard to trace how information flowed. What architectural principle should guide the redesign?

    • A. Keep the peer-to-peer calls but add a shared logging database so every direct call is recorded for observability.
    • B. Give each subagent the full tool set so it can complete any downstream step itself without calling a peer.
    • C. Have every subagent broadcast its output to a shared global-memory bus that the others poll.
    • D. Route all inter-subagent communication through the coordinator, which manages delegation, result routing, and consistent error handling.
  7. Agentic Architecture Logs show your returns agent sometimes calls issue_store_credit before it has run validate_return_eligibility, occasionally granting credit for items outside the return window. A strongly worded system-prompt rule has not eliminated the problem. What most reliably enforces the required ordering?

    • A. Add few-shot examples showing the agent always validating eligibility before issuing credit.
    • B. Rephrase the system-prompt rule more forcefully and place it at the top of the prompt.
    • C. Add an intent classifier that only enables issue_store_credit for requests it labels as valid returns.
    • D. Implement a programmatic prerequisite gate that blocks issue_store_credit until validate_return_eligibility has returned an eligible result.
  8. Agentic Architecture Your CI code review must always examine every pull request for the same three predetermined aspects — security, performance, and style — and a single combined pass produces shallow, inconsistent results. Which task-decomposition strategy fits this predictable, multi-aspect review?

    • A. Use a fixed prompt chain that runs a focused pass for each aspect in sequence (security, then performance, then style).
    • B. Use adaptive decomposition that generates new review aspects on the fly based on what each pass discovers.
    • C. Run one pass over the whole PR with a larger-context model so all three aspects fit at once.
    • D. Spawn one subagent per changed line and merge their raw outputs.
  9. Tool Design & MCP Production logs show the agent frequently calls get_customer when users ask about orders (e.g., 'check my order #12345'), instead of calling lookup_order. Both tools have minimal descriptions ('Retrieves customer information' / 'Retrieves order details') and accept similar identifier formats. What's the most effective first step to improve tool selection reliability?

    • A. Add few-shot examples to the system prompt demonstrating correct tool selection patterns, with 5-8 examples showing order-related queries routing to lookup_order.
    • B. Expand each tool's description to include input formats it handles, example queries, edge cases, and boundaries explaining when to use it versus similar tools.
    • C. Implement a routing layer that parses user input before each turn and pre-selects the appropriate tool based on detected keywords and identifier patterns.
    • D. Consolidate both tools into a single lookup_entity tool that accepts any identifier and internally determines which backend to query.
  10. Tool Design & MCP You want Claude Code to find all occurrences of a specific import statement in a multi-directory project. Which built-in tool should you instruct the agent to use?

    • A. Glob
    • B. Grep
    • C. Read
    • D. Bash
  11. Tool Design & MCP Your extraction pipeline must guarantee that extract_metadata runs first — before any enrichment tools — as a single deterministic step at the start of the turn. Which tool_choice configuration achieves exactly this?

    • A. tool_choice: "auto", relying on the model to usually pick extract_metadata first.
    • B. tool_choice: "any", so the model is guaranteed to call a tool but chooses which one.
    • C. tool_choice: {"type": "tool", "name": "extract_metadata"} to force that specific tool, then process enrichment in follow-up turns.
    • D. tool_choice: "required" with a priority field listing extract_metadata first.
  12. Tool Design & MCP Your support agent's process_refund MCP tool returns a generic 'Operation failed' whenever a refund is rejected because it exceeds the customer's eligible amount (a policy violation). In production the agent keeps calling process_refund again and again on these rejections, wasting calls and never explaining the outcome to the customer. How should the tool structure this failure?

    • A. Return isError: true with errorCategory: transient and isRetryable: true so the agent retries until the refund eventually goes through.
    • B. Return isError: true with errorCategory: business, isRetryable: false, and a customer-friendly explanation so the agent stops retrying and communicates or escalates appropriately.
    • C. Return an empty successful result so the agent treats the refund as done and moves on.
    • D. Throw a terminal exception in the MCP server so the whole session restarts and clears the failed attempt.
  13. Tool Design & MCP A developer on your team wants to try an experimental personal MCP server on their own machine while iterating on it. It should not affect teammates and must not be committed to the shared repo configuration. Where should they configure it?

    • A. In the project-scoped .mcp.json so it is discovered by everyone who clones the repo.
    • B. In the user-scoped ~/.claude.json, so the server stays personal and is not shared via version control.
    • C. Under an MCP section inside the project root CLAUDE.md so the agent loads it as context.
    • D. In a .claude/mcp-local.json file that Claude Code automatically git-ignores for personal servers.
  14. Claude Code Configuration A new developer joins your team and notices that Claude Code is not following the project's standard naming conventions, despite other team members having no issues. What is the most likely cause of this discrepancy?

    • A. The naming conventions were defined in the user-level configuration (~/.claude/CLAUDE.md) of the existing developers instead of the project-level root.
    • B. The new developer forgot to run the /memory command to index the project's folder hierarchy.
    • C. The project is using glob-scoped rules which are blocked by default on new installations.
    • D. The naming conventions were set inside a directory-level CLAUDE.md file that the agent cannot access.
  15. Claude Code Configuration You want Claude Code to implement a complex caching mechanism. To ensure the implementation covers edge cases like cache stampede and failure modes, what technique should you use before coding begins?

    • A. Provide a monolithic system prompt listing all cache stampede failure scenarios.
    • B. Use the interview pattern by instructing Claude to ask clarifying questions about invalidation, TTL, and failure modes before writing code.
    • C. Run the task in direct execution mode and iterate based on compiler error logs.
    • D. Create a custom skill with allowed-tools restricted to 'Read' and 'Grep'.
  16. Claude Code Configuration Your platform has dozens of microservice directories, and every service exposes its entry point in a file named handler.ts. You need Claude to apply the same error-handling and logging conventions to all of these handler files, no matter which service directory they live in, without maintaining config in every folder. What is the most maintainable configuration?

    • A. Put all handler conventions under a heading in the root CLAUDE.md and rely on the agent to infer when a file is a handler.
    • B. Place a CLAUDE.md file inside each microservice directory containing the handler conventions.
    • C. Store the conventions in a .claude/config.json file keyed by the filename handler.ts.
    • D. Create a file in .claude/rules/ with YAML frontmatter paths: ["**/handler.ts"] so the conventions load automatically whenever a handler file is edited, regardless of directory.
  17. Claude Code Configuration A developer reports that Claude Code behaves inconsistently between sessions — sometimes it follows a specific project rule and sometimes it ignores it. You suspect a memory file is not loading reliably. What is the correct way to diagnose which memory files are actually in effect?

    • A. Run /memory to view which memory files are currently loaded and verify the rule's source file is among them.
    • B. Run /memory to re-index the project's folders so every CLAUDE.md is reloaded into memory.
    • C. Add the rule to ~/.claude/CLAUDE.md so it loads globally and overrides the session inconsistencies.
    • D. Increase max_tokens so the full CLAUDE.md always fits in context on every session.
  18. Claude Code Configuration Your repository contains Terraform infrastructure code, and every .tf file must follow strict tagging and naming conventions. These Terraform files are spread across many different directories. What is the most maintainable way to ensure Claude applies these conventions only when editing Terraform files?

    • A. Place a CLAUDE.md inside each directory that contains Terraform files.
    • B. Create a .claude/rules/ file with YAML frontmatter paths: ["**/*.tf"] so the conventions load only when editing Terraform files.
    • C. Put the Terraform conventions in the root CLAUDE.md and rely on the agent to infer when a file is Terraform.
    • D. Register the conventions in a .claude/config.json keyed by the .tf extension.
  19. Claude Code Configuration You have described a data-normalization transformation to Claude in prose several times, but it keeps interpreting the output format inconsistently across records. What is the most effective way to communicate the exact transformation you expect?

    • A. Rewrite the prose description with more forceful, detailed wording until it is unambiguous.
    • B. Provide 2-3 concrete input/output examples that demonstrate the exact transformation you expect.
    • C. Use the interview pattern so Claude asks clarifying questions about the format before transforming.
    • D. Lower the model temperature so the output format stays consistent across records.
  20. Prompt & Structured Output Your automated code review prompt flags standard console logs as high-severity security vulnerabilities. Developers are losing trust in the tool. How should you address this issue?

    • A. Add general instructions to the prompt such as 'be conservative' and 'only report high-confidence findings'.
    • B. Define explicit review criteria with concrete code examples distinguishing acceptable log patterns from genuine vulnerabilities.
    • C. Switch to a larger, more expensive model to improve overall reasoning capabilities.
    • D. Configure tool_choice to force the review agent to use the Bash tool to inspect log directories.

…và 100 câu nữa trong bản đề thi thử đầy đủ (120 câu) — mở tab “Đề thi thử” trên trang để làm toàn bộ, có chấm điểm & giải thích.