Claude Certified Architect — Foundations (CCA-F)

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

Đề thi CCA-F gồm các câu hỏi dựa trên tình huống sản xuất thực tế. Theo Exam Guide chính thức bản 1.0 (hiệu lực 07/2026, mã kỳ thi CCAR-F — trang này gọi tắt là CCA-F cho gọn), đề gồm 60 câu / 120 phút, điểm đậu 720/1.000 (thang 100–1.000), và câu hỏi có cả dạng chọn một đáp án (multiple choice) lẫn chọn nhiều đáp án (multiple response) — mỗi câu ghi rõ cần chọn bao nhiêu ý. 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 (chi tiết "mỗi block 15 câu" là từ báo cáo của thí sinh đã thi — Exam Guide không nêu con số này):

• 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).

Nguồn: phần mô tả bối cảnh của 6 scenario hiển thị trong bộ đề thi thử bên dưới được trích nguyên văn tiếng Anh từ Exam Guide chính thức của Anthropic (bản 1.0, hiệu lực 07/2026), để bạn làm quen đúng cách diễn đạt và đúng bộ tên tool sẽ gặp trong phòng thi. Câu hỏi, đáp án và phần giải thích là do tôi tự biên soạn.

#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.

#Bảng thần chú: 6 nhóm dữ kiện phải thuộc lòng

12 quy luật trên là phán đoán — nắm được nguyên tắc thì suy ra được đáp án. Sáu nhóm dưới đây thì không: chúng là tên trường, giá trị hằng và con số cụ thể. Nhớ sai một chữ là mất điểm trắng, không lý luận nào cứu được. Tôi tách riêng ra đây để đọc lại lần cuối ngay trước giờ thi.

#1. Vòng lặp agentic — stop_reason cầm lái, tool_result nuôi lại lịch sử

Ba distractor kinh điển: dừng vòng lặp bằng bộ đếm (bỏ qua stop_reason), ném exception ra ngoài khi tool lỗi, và viết if "tool_use" ... else: break. Hai cái đầu cắt mất khả năng tự phục hồi của agent. Cái thứ ba âm thầm hơn: else gom hết mọi giá trị còn lại vào cùng một rọ, nên một câu trả lời bị cắt vì chạm trần max_tokens được ghi nhận như đã hoàn thành.

Lưu ý phạm vi. Exam Guide chỉ liệt kê hai giá trị "tool_use" / "end_turn", nhưng Messages API thật trả về bảy: thêm "max_tokens", "stop_sequence", "pause_turn", "refusal", "model_context_window_exceeded". Đề có câu lấy "max_tokens" làm đáp án đúng, nên đừng học thuộc bảng hai dòng.

Thần chú: tool_use thì đi tiếp, end_turn thì dừng, max_tokens là bị cắt — đừng nhét chung vào else. Lỗi cũng phải trả về cho model, đừng nuốt.

#2. Lỗi trả về phải có cấu trúc — isError + errorCategory + isRetryable

Tool MCP thất bại thì không được trả một chuỗi text mô tả lỗi. Phải trả đủ bộ ba để agent hành động được:

{
  "isError": true,
  "errorCategory": "business",
  "isRetryable": false,
  "message": "Đơn hàng đã quá hạn hoàn tiền 30 ngày."
}

Bốn giá trị errorCategory cần thuộc: transient (nghẽn mạng, timeout — thử lại được), business (vi phạm quy tắc nghiệp vụ — thử lại vô ích), validation (input sai — phải sửa rồi mới gọi lại), permission (không đủ quyền — phải leo thang). Thiếu isRetryable là agent retry mù: thử lại một lỗi nghiệp vụ mười lần cũng chỉ ra đúng một kết quả.

Đi kèm là một luật hay bị bỏ sót: kết quả rỗng không phải là lỗi. Tool phải trả về hai thứ khác hẳn nhau cho "query chạy đúng, khớp 0 dòng" và "không truy cập được nguồn". Gộp cả hai thành mảng rỗng là anti-pattern nặng nhất trong Domain 5 — coordinator không bao giờ biết là có chuyện cần cứu.

Thần chú: Lỗi phải nói được: loại gì, thử lại có ích không. Rỗng khác hỏng.

#3. tool_choice — ba giá trị, và cái giá phải trả của "any"

Cái giá của "any" là câu hỏi bẫy hay gặp: nó ép gọi tool cả khi câu trả lời thường mới là đúng, nên agent sẽ bịa ra việc để làm. Đặt "any" cho một agent hội thoại là tự tạo ra tool call rác.

Thần chú: auto cho phép im lặng, any bắt phải làm gì đó, {"type":"tool"} chỉ mặt điểm tên.

#4. Schema chống bịa — nullable, unclear, other, và giới hạn của strict

Nguyên nhân gốc của việc model bịa dữ liệu trích xuất không phải ở prompt, mà ở schema không chừa chỗ cho sự thật "tài liệu này không có thông tin đó". Bị ép phải điền cho đủ khuôn, model sẽ điền.

• Trường có thể vắng mặt một cách hợp lệ → để nullable: "type": ["string", "null"], kèm description nói rõ trả null khi không tìm thấy.
• Enum phân loại → luôn có "unclear" cho tài liệu đọc không ra, và "other" đi kèm một trường detail dạng chuỗi cho loại chưa lường trước.
• Ép required cho trường có thể khuyết là tự tay tạo ra áp lực khiến model bịa. Cho phép chuỗi "N/A" cũng không cứu được: hợp lệ về schema nhưng vẫn là dữ liệu bịa — phải chặn ở tầng validation.
• strict mode chỉ diệt lỗi cú pháp, không diệt lỗi ngữ nghĩa. JSON đúng khuôn hoàn toàn vẫn có thể có các line item cộng lại không bằng tổng. Muốn bắt thì phải tự thêm bước sum-check, đừng trông vào strict.
• Retry chỉ chữa được lỗi định dạng. Thông tin thực sự không tồn tại trong tài liệu nguồn thì thử lại bao nhiêu lần cũng vậy — chỉ đốt tiền và đẩy model tới chỗ bịa. Đúng việc phải làm là nhận diện rồi route sang người duyệt.

Thần chú: Chừa chỗ cho null thì model không phải bịa. strict bắt cú pháp, không bắt ý nghĩa.

#5. Hiệu chuẩn & lấy mẫu — chỗ Domain 5 âm thầm lấy điểm

Domain 5 chỉ 9 câu mỗi đề nhưng là nhóm dễ mất nhất, vì ba ý dưới đây không suy ra được bằng trực giác kỹ sư:

• Confidence phải ở mức từng trường (field-level), không phải một điểm số cho cả tài liệu, và ngưỡng phải được hiệu chuẩn trên một tập validation đã gán nhãn — không phải chọn bằng cảm tính.
• Câu bẫy kinh điển: độ chính xác tổng 97% không đủ để giảm human review. Phải bóc nhỏ theo từng loại tài liệu và từng trường rồi mới kết luận — một loại giấy tờ hiếm có thể đang sai 40% mà vẫn bị con số tổng che đi.
• Stratified sampling: lấy mẫu ngẫu nhiên phân tầng trong nhóm high-confidence để audit định kỳ. Lý do là cơ cấu tài liệu đầu vào trôi theo thời gian, nên tỷ lệ lỗi thật sẽ đổi mà không ai nhìn thấy nếu chỉ đo một lần lúc nghiệm thu.
• Về provenance: tách claim khỏi metadata nguồn (URL, tên tài liệu, ngày) ngay tại bước hand-off giữa các agent. Nguồn nào không đọc được thì ghi coverage gap tường minh vào báo cáo. Hai số liệu mâu thuẫn thì báo cả hai kèm nguồn và ngày thu thập, tuyệt đối không tự chọn lấy một.

Thần chú: Con số tổng luôn nói dối. Bóc theo loại tài liệu và theo trường, rồi mới dám giảm người duyệt.

#6. Cấu hình và con số — sai một ký tự là sai cả câu

Nhóm này không có gì để hiểu, chỉ có nhớ đúng mặt chữ. Đổi lại, hỏi tới là ăn điểm ngay.

SKILL.md — Exam Guide chỉ tính ba trường frontmatter: context: fork (chạy trong subagent tách biệt, output dài không làm bẩn hội thoại chính) · allowed-tools (khoanh tập tool ở cấp skill) · argument-hint (nhắc tham số còn thiếu khi bị gọi trống). Gặp option bịa hẳn một cơ chế cấu hình không tồn tại — kiểu .claude/config.json — thì loại ngay.

⚠️ Hai chỗ đừng nhớ nhầm ở trường allowed-tools.

Một — chiều tác dụng. Docs Claude Code hiện hành mô tả allowed-tools là CẤP QUYỀN TRƯỚC (pre-approve: các tool trong danh sách chạy khỏi hỏi phép, và quyền đó hết hiệu lực ngay khi bạn gửi tin nhắn kế tiếp), không phải chặn cứng — mọi tool ngoài danh sách vẫn gọi được bình thường qua permission model. Trường thật sự gỡ tool khỏi tay Claude là disallowed-tools; muốn cấm bền xuyên mọi skill thì dùng deny rule trong permissions của settings.json (thứ tự chấm: deny → ask → allow, nên deny rule thắng cả allowed-tools). Dù vậy Exam Guide v1.0 chấm allowed-tools theo nghĩa "giới hạn tool", và guide không hề nhắc disallowed-tools — vào phòng thi cứ chọn allowed-tools, nhưng đừng mang cách hiểu đó ra đời thật.

Hai — đừng lẫn với allowedTools viết liền. allowed-tools (có gạch ngang) là frontmatter của SKILL.md trong Claude Code. allowedTools (camelCase) là tham số top-level của Agent SDK / CLI. Exam Guide có điểm ra đề riêng ở đây: coordinator muốn spawn subagent thì allowedTools phải chứa "Task" — vào phòng thi cứ chọn theo vế đó. Thấy chữ viết liền là câu đang hỏi SDK, không phải hỏi skill.

Ba — nhưng allowedTools cũng KHÔNG phải danh sách giới hạn. Docs Agent SDK hiện hành ghi nó là lớp tự động duyệt: thiếu tool trong đó thì lời gọi rơi xuống callback canUseTool, và chỉ bị từ chối thẳng khi chạy permissionMode: "dontAsk" mà không có callback nào. Thứ thật sự giới hạn tool của một subagent cụ thể là AgentDefinition.tools (bỏ trống thì kế thừa toàn bộ), gỡ bớt bằng AgentDefinition.disallowedTools, cấp MCP server riêng bằng AgentDefinition.mcpServers. AgentDefinition không có field allowedTools — thấy chữ đó trong một option là dấu hiệu distractor. Và từ Claude Code v2.1.63 tool spawn subagent đã đổi tên Task → Agent (Task còn làm alias ở system:init và permission_denials); Exam Guide v1.0 vẫn viết Task, nên trong phòng thi nhận diện theo cơ chế chứ đừng bám mặt chữ.

CLAUDE.md xếp chồng chứ không loại trừ nhau: file ở ~/.claude/CLAUDE.md (user), ở gốc project và ở thư mục con cùng load và cộng dồn, chỗ nào cụ thể hơn thì chỗ đó thắng khi có mâu thuẫn. Không hề tồn tại luật "chỉ lấy file gần nhất" hay "chỉ lấy file gốc" — gặp option nói vậy là loại ngay. Muốn biết thực tế đang load những file nào thì chạy /memory.

Message Batches API — năm dữ kiện: rẻ hơn 50% · cửa sổ xử lý tối đa 24 giờ · đối chiếu request với response bằng custom_id · lấy kết quả bằng polling (tạo batch → giữ id → poll tới khi ended → đọc kết quả; không có callback) · không hỗ trợ multi-turn tool calling trong một request. Dữ kiện cuối là chỗ bị hỏi nhiều nhất: workflow cần gọi tool giữa chừng rồi đi tiếp thì không bê sang Batch được, dù có thèm khoản tiết kiệm 50% đến mấy.

⚠️ Dữ kiện thứ tư chỉ đúng với client tool. Docs 08/2026 nói rõ server tool — web search, web fetch, code execution, MCP connector, advisor, tool search — chạy được cả agentic loop bên trong batch, y như request đồng bộ, chỉ khác là trần vòng lặp mỗi lượt cao hơn; chạm trần thì trả stop_reason: "pause_turn" để bạn nộp tiếp. Thứ batch thật sự không làm được là client tool do chính bạn host, vì vòng tool_use → chạy tool → tool_result cần một request mới mà batch đã nộp không có đường quay lại. Trong phòng thi cứ chấm theo Exam Guide v1.0; ngoài đời thì hỏi thêm một câu: tool này ai chạy? Hai con số hay đi kèm: một batch giới hạn 100.000 request hoặc 256 MB, và request errored / canceled / expired không bị tính tiền.

Thần chú: Thiếu -p là CI treo. SKILL.md ba trường, allowed-tools có gạch ngang là skill — viết liền là SDK. CLAUDE.md cộng dồn, cụ thể thắng. Batch: 50%, 24 giờ, custom_id, không multi-turn.

#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)

• 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)

• 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)

• 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 — tổng thời gian khi đó bị chặn bởi nhánh chậm nhất thay vì bằng tổng ba nhánh cộng lại (tôi chưa đo con số cụ thể trên hệ thống của mình).
• 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.

#Checklist tự dựng: 4 bài thực hành trong Exam Guide

Exam Guide có hẳn mục Preparation Exercises với 4 bài dựng tay, và mục "Exam Preparation Recommendations" thì 7/7 gạch đầu dòng đều là build chứ không phải đọc. Đây là phần dễ bỏ qua nhất nhưng lại đúng chỗ đề kiểm tra — thí sinh đạt điểm cao nhất mà tôi đọc được báo cáo dành khoảng 80% thời gian ôn để dựng thật. Tôi chuyển 4 bài đó thành checklist, kèm link tới ghi chú tương ứng trên site để tra cú pháp khi mắc.

Bài 1 — Agent nhiều tool có escalation (Domain 1 · 2 · 5)

• Định nghĩa 3–4 MCP tool, trong đó cố ý để 2 tool chức năng gần nhau rồi viết description phân biệt được chúng
• Cài agentic loop điều khiển bằng stop_reason, xử lý đúng cả "tool_use" lẫn "end_turn"
• Thêm structured error: errorCategory, isRetryable, message người đọc được — test đủ 3 loại lỗi
• Cài hook chặn tool call vi phạm ngưỡng nghiệp vụ, chuyển hướng sang escalation
• Test bằng tin nhắn nhiều vấn đề cùng lúc, xem agent có phân rã rồi tổng hợp lại thành một câu trả lời không

Tra cứu: Tool use với Claude API · Agentic workflows với Claude · Model Context Protocol

Bài 2 — Cấu hình Claude Code cho team (Domain 3 · 2)

• CLAUDE.md project-level chứa chuẩn code + cách chạy test, commit vào repo
• File trong .claude/rules/ có paths glob, kiểm chứng rule chỉ nạp khi sửa file khớp
• Một skill trong .claude/skills/ dùng context: fork + allowed-tools, xác nhận nó chạy cô lập
• MCP server trong .mcp.json với biến môi trường, cộng một server cá nhân ở ~/.claude.json — kiểm tra cả hai cùng khả dụng
• So plan mode vs thực thi trực tiếp trên 3 mức việc: sửa bug 1 file, migrate nhiều file, tính năng có nhiều hướng làm

Tra cứu: Claude Code in Action · Agent Skills · MCP nâng cao

Bài 3 — Pipeline trích xuất có cấu trúc (Domain 4 · 5)

• Extraction tool với JSON schema: trường required, trường nullable, enum có "other" + chuỗi chi tiết
• Chạy trên tài liệu thiếu thông tin và xác nhận model trả null thay vì bịa
• Vòng validation-retry: gửi lại kèm tài liệu gốc + bản lỗi + thông báo validation; ghi lại lỗi nào retry được, lỗi nào không
• Few-shot cho tài liệu khác định dạng (inline citation vs bibliography, văn xuôi vs bảng)
• Batch 100 tài liệu qua Message Batches API, xử lý lỗi theo custom_id, tính thời gian so với SLA
• Confidence cấp trường + định tuyến ca thấp điểm sang duyệt tay, rồi đo độ chính xác theo từng loại tài liệu

Tra cứu: Claude API cơ bản · Tool use với Claude API · Prompt engineering & evaluation

Bài 4 — Hệ nghiên cứu multi-agent (Domain 1 · 2 · 5)

• Coordinator có "Task" trong allowedTools, mỗi subagent nhận context tường minh trong prompt, không trông chờ thừa kế
• Spawn song song: phát nhiều Task call trong cùng một response, đo độ trễ so với gọi tuần tự
• Output subagent tách content khỏi metadata: claim, excerpt, nguồn, ngày xuất bản — kiểm tra synthesis có giữ được attribution không
• Giả lập subagent timeout, xác nhận coordinator nhận đủ error context và vẫn chạy tiếp được với kết quả một phần
• Đưa vào 2 nguồn uy tín mâu thuẫn số liệu, xem báo cáo có giữ cả hai kèm nguồn thay vì tự chọn một

Tra cứu: Subagents · Agentic workflows với Claude · Domain 1

Làm xong 4 bài này là đã chạm tay vào gần hết 30 task statement của đề. Phần lý thuyết còn thiếu thì tra ở 5 note domain bên dưới; còn phán đoán tradeoff — thứ đề thật kiểm tra — thì chỉ có va thực tế mới ra được.

#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:

• Domain 1: Agentic Architecture & Orchestration (Trọng số 27%) — Agentic loop, điều phối multi-agent, hooks chặn tool call, quản lý state và resume session.
• Domain 2: Tool Design & MCP Integration (Trọng số 18%) — Thiết kế tool interface, structured error response, scoped tools, tích hợp MCP servers và các built-in tools.
• Domain 3: Claude Code Configuration & Workflows (Trọng số 20%) — Cấu hình CLAUDE.md hierarchy, path rules, skills, plan mode vs direct execution và CI/CD integration.
• Domain 4: Prompt Engineering & Structured Output (Trọng số 20%) — Few-shot prompting, JSON Schema, validation-retry loop, Message Batches API và multi-pass review.
• Domain 5: Context Management & Reliability (Trọng số 15%) — Tối ưu context window, "lost in the middle", escalation patterns, confidence calibration và provenance dữ liệu.

#5. Phạm vi thi: có và không

#Checklist In-Scope — 18 chủ đề chắc chắn bị hỏi

Exam Guide liệt kê tường minh 18 chủ đề được kiểm tra. Dùng bảng này làm bước rà cuối: tự hỏi "mình giải thích được chủ đề này cho người khác chưa", chỗ nào lắc đầu thì mở đúng ghi chú domain ở cột bên phải.

Làm 12 câu mẫu chính chủ trước khi thi. Exam Guide (§9) có 12 câu hỏi mẫu kèm đáp án và phần giải thích do chính Anthropic viết. Đây là nguồn chính thức để đối chiếu dạng câu, cách diễn đạt và rationale — không phải mẫu đủ lớn để suy ra độ khó thống kê của toàn kỳ thi; bộ 600 câu ở trang này dù bám blueprint vẫn là do tôi tự biên soạn. Tải Exam Guide từ Partner Academy và làm hết 12 câu đó; đừng bỏ qua phần rationale, vì nó cho thấy Anthropic muốn bạn loại phương án nhiễu theo lối nào.

#Những gì KHÔNG thi (Out-of-Scope)

Exam Guide liệt kê tường minh các chủ đề không xuất hiện trong đề — biết trước để khỏi ôn lan man:

#6. Chiến thuật phòng thi & kinh nghiệm người đã thi

Phần này tôi tổng hợp từ báo cáo công khai của các thí sinh đã đậu CCA-F trong năm 2026 (các bài viết chi tiết của test-taker trên verygood.ventures, loginov-rocks…). Đây là những điểm Exam Guide không nói nhưng ảnh hưởng trực tiếp tới kết quả — lọc qua góc nhìn thực chiến, không phải chép câu hỏi.

Biên độ đậu mỏng hơn tưởng. Có thí sinh đậu ở mức 738/1.000 và tự nhận "sai thêm một câu nữa là trượt". Ngưỡng 720 không hề dư dả; đừng chủ quan vì đã cày hết Course. (Lưu ý cách đọc con số: 738 là scaled score, thang được equate giữa các form khác độ khó, và chương trình thi không công bố raw cut score — nên không có phép quy đổi nào ra "bao nhiêu câu đúng". Mọi mốc số-câu bạn thấy trên mạng, kể cả các mốc ở tab "Đề thi thử" của trang này, đều là ngưỡng thủ thế tự đặt, không phải dự đoán điểm đậu.)

Phân bổ thời gian theo block. 60 câu / 120 phút = ~2 phút/câu. Vì câu hỏi cluster theo scenario (15 câu/block), hãy đọc kỹ bối cảnh scenario một lần rồi giữ trong đầu cho cả 15 câu của block đó — tránh đọc lại nhiều lần cho từng câu. Nhắm ~30 phút/block, chừa thời gian rà lại.

Practice ≠ đề thật. Các thí sinh đều xác nhận đề thật không trùng câu nào với practice exam ("nothing looked familiar") — điểm practice cao không bảo chứng gì. Practice để rèn tư duy phán đoán, không phải học thuộc câu. Đây cũng là lý do bộ đề thử ở tab "Đề thi thử" được soạn theo 12 quy luật (mục 2) chứ không chép câu gốc. (Lưu ý: Exam Guide bản 1.0 đã bỏ hẳn phần trỏ tới practice exam có ở bản nháp trước — đừng trông chờ Anthropic phát đề luyện chính chủ.)

Ôn hiệu quả nhất = làm tay, không phải đọc. Người đậu điểm cao (886/1.000) dành khoảng 80% thời gian ôn để BUILD thật — dựng agent, MCP server, pipeline trích xuất — chỉ ~20% đọc tài liệu. Nếu đã học xong lý thuyết, bước giá trị nhất tiếp theo là tự dựng lại 4 hệ thống mẫu ở mục 3 bằng tay, vì đề kiểm tra phán đoán tradeoff chỉ có khi va thực tế.

Đừng bỏ bê domain "dễ". Điểm yếu mỗi người mỗi khác: có thí sinh mạnh Agentic Architecture (phần khó nhất, 27%) nhưng lại chỉ ~50% ở Prompt Engineering & Structured Output — domain tưởng nhẹ. Ôn đều cả 5 domain, đừng dồn hết công vào phần nặng ký nhất.

Cẩn thận cú pháp lỗi thời. Một vài câu dùng flag/cú pháp đã cũ so với docs hiện tại. Chọn đáp án theo nguyên tắc kiến trúc (mục 2) thay vì bám cú pháp bề mặt — khớp với quy luật #10 (cảnh giác tính năng/flag tự bịa).

#7. Thủ tục dự thi: đăng ký, giấy tờ, huỷ lịch, thi lại

Phần này Exam Guide v1.0 mới bổ sung (§11–§16) và hoàn toàn không phải kiến thức chuyên môn — nhưng sai ở đây thì ôn giỏi mấy cũng không ngồi được vào phòng thi, hoặc mất trắng phí. Tôi tách riêng vì mấy điều khoản này dễ bị bỏ qua nhất.

#Đăng ký

Luồng đăng ký đi qua Anthropic Partner Academy rồi mới sang Pearson VUE: vào trang certification trên Partner Academy → tải Exam Guide, đọc Certification Terms and Conditions + Certification Exam Policy → đăng ký và checkout (phí hiển thị đã trừ discount theo partner tier, nên con số bạn thấy có thể thấp hơn $125 niêm yết) → tạo tài khoản Pearson VUE → đặt lịch, chọn online proctored hoặc test center.

Điều kiện dự thi (nhiều người vấp ngay từ đây): phải là nhân sự của một tổ chức trong Claude Partner Network — cá nhân tự đăng ký network là không đủ — và phải dùng email công ty trên domain đã được Anthropic nhận diện; email cá nhân sẽ không đăng ký được. Tối thiểu 18 tuổi.

Vài mốc thời gian đáng lưu vào lịch: đăng ký sau khi mua có hiệu lực 5 năm (không phải mua là buộc thi ngay); cần accommodations thì xin trước ít nhất 10 ngày; và tổng thời gian ngồi phòng thi là khoảng 135 phút — 120 phút làm bài cộng check-in, hướng dẫn và một khảo sát ngắn cuối buổi.

#Ba điều khoản dễ mất tiền nhất

#Trong phòng thi

Thi online thì phải ở trong tầm nhìn webcam/proctor suốt buổi; bàn sạch — không ghi chú, sách, điện thoại, màn hình phụ; không giao tiếp với ai; không chụp/sao chép/tái tạo nội dung đề dưới bất kỳ hình thức nào. Vi phạm là huỷ kết quả, thu hồi chứng chỉ, cấm thi.

Trước khi bắt đầu còn phải chấp nhận NDA — nội dung đề (câu hỏi, đáp án, scenario) là tài sản độc quyền của Anthropic. Không chấp nhận thì buổi thi kết thúc ngay và không hoàn phí.

#Trượt thì sao

Thời gian chờ tăng dần, và mỗi lần thi đều tính phí:

Tối đa 4 lần thi trong 12 tháng luân phiên (tính riêng cho từng kỳ thi). Cộng với biên độ đậu mỏng đã nói ở mục 6, kết luận thực dụng là: đừng đi thi để thăm dò. Một lần trượt tốn thêm $125 và ít nhất hai tuần.

Khiếu nại thì gửi qua Pearson VUE support trong 14 ngày kể từ khi được thông báo (hoặc kể từ ngày thi nếu khiếu nại kết quả). Lưu ý: kết quả standard-setting và nội dung từng câu hỏi không thuộc diện khiếu nại — chỉ khiếu nại được về quy trình.

#Sau khi đậu

Kết quả pass/fail hiện ngay cuối buổi thi. Sau đó bạn nhận email từ Credly — nền tảng badge số của chương trình — mời nhận huy hiệu; chứng chỉ PDF cũng lấy từ đó.

Chứng chỉ có hiệu lực 12 tháng kể từ ngày cấp. Gia hạn đúng hạn thì chỉ cần xem lại phần nội dung đã thay đổi rồi làm một assessment miễn phí, không proctored trên Partner Academy. Để hết hạn là phải thi lại full, trả full phí. Nếu nội dung đề đổi lớn, Anthropic vẫn có quyền buộc thi lại full thay vì cho renewal.

Checklist trước khi bấm đặt lịch: tên trên Pearson VUE khớp từng ký tự với giấy tờ · giấy tờ còn hạn tới sau ngày thi · đã chốt online proctored hay test center · nếu cần accommodations thì đã xin duyệt xong · đã lưu mốc "trước 24h" vào lịch · phòng thi (nếu online) dọn được sạch bàn và có webcam ổn định.

#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ử".

Nguồn: Claude Certified Architect – Foundations Certification Exam Guide (Anthropic, Version 1.0 — hiệu lực 07/2026) — Copyright Anthropic. Phần đề thi thử cho kỳ thi này nằm ở tab "Đề thi thử".