Learning Guide – Claude Certified Architect – Foundations (CCA-F) certification

Core Domains & Foundational Concepts

The certification evaluates your ability to orchestrate reliable, end-to-end AI workflows across five weighted domains:

• Agentic Architecture & Orchestration: Master dynamic task decomposition, prompt chaining, and orchestrator-worker patterns to replace rigid, fixed sequences.
• Context Management & Reliability: Understand session resumption techniques like fork_session, targeted re-reading of modified files, and managing stale tool results during context degradation.
• Tool Design & MCP Integration: Learn to connect Model Context Protocol (MCP) servers, disambiguate overlapping tool descriptions, and handle execution errors using structured is_error: true flags.
• Structured Data Extraction: Design JSON schema-based extractions, manage nullable fields, and implement retry-with-error-feedback loops alongside human-in-the-loop confidence thresholds.
• Claude Code Configuration: Command developer workflows using plan mode versus direct execution, .claude/rules/ path-scoped guidelines, and PreToolUse/PostToolUse hooks to enforce strict architectural boundaries.

Domain 1 — Agentic architecture & orchestration (27%)

The foundational idea the exam keeps testing: an agent isn’t a chatbot with more steps — it’s an LLM operating a loop where its own outputs steer what happens next.

Under that loop, the exam expects you to reason about three layers of decisions: when to use an agent at all (workflows with fixed control flow often beat agents on cost, latency, and auditability — start simple and only add agentic behavior where a workflow fails), how to decompose a goal into subtasks (hierarchical, sequential, or parallel, watching for over-decomposition and false parallelism), and how multiple agents coordinate once a single agent isn’t enough.

That third piece — multi-agent orchestration — gets its own visual, because the topology you choose changes everything about cost, latency, and failure isolation:

The rest of domain 1 is reliability engineering for agents: classifying failures as tool errors, reasoning errors, or environment errors (each needs a different recovery strategy); designing fallback chains and graceful degradation; and knowing when a prompt-based guardrail isn’t enough and you need a programmatic validation layer with hard blocks for high-stakes, irreversible actions.

Key Concepts to Master:

• Orchestration Patterns: Understand the difference between simple chains, routers, and parallel execution.
• Delegation: How a ‘Manager’ or ‘Orchestrator’ agent breaks down a complex task and assigns sub-tasks to specialized ‘Worker’ agents.
• Aggregation: Synthesizing the outputs from multiple sub-agents into a cohesive final response.

Domain 2 — Tool design & MCP integration (18%)

This domain splits into two halves: writing tools Claude can reliably select and call, and understanding the Model Context Protocol that standardizes how those tools get exposed.

On the tool-design side, the exam leans hard on description quality — Claude routes to tools through semantic matching against the description, so a vague description causes misrouting long before the schema matters. Add tight input schemas (required vs. optional, enums, constraints), useful structured errors (stable code, message, failing input, suggested next action), and idempotency for anything retried. On the MCP side: three primitives (tools, resources, prompts), two transports (stdio for local single-user servers, streamable HTTP for remote production ones), and production hardening via OAuth 2.1, versioning, rate limiting, and least-privilege scoping.

Key Concepts to Master:

• Tool Definition: How to precisely define function names, descriptions, and JSON parameters so Claude can generate correct tool calls.
• Model Context Protocol (MCP): Understanding this open standard is paramount. MCP allows you to build universal ‘connectors’ (MCP Servers) that let Claude easily and securely query any data source (databases, local files, APIs) that implements the protocol, replacing bespoke, brittle tool definitions.

Domain 3 — Claude Code configuration & workflows (20%)

The core of this domain is the CLAUDE.md configuration hierarchy — knowing which scope wins when instructions conflict:

Beyond CLAUDE.md, this domain covers the tool system (Read, Write, Edit, Bash, Glob, Grep, WebSearch, WebFetch), custom slash commands, Skills (SKILL.md frontmatter and triggers), subagents (scope and delegation), hooks (lifecycle events with exit-code conventions for safety nets and automation), and the Claude Agent SDK for programmatic session control — including non-interactive -p mode for CI/CD integration.

Key Concepts to Master:

• Model Selection: When to choose Claude 3.5 Sonnet (for best balance of speed and coding intelligence), Claude 3 Opus (for maximum reasoning and complexity), or Claude 3 Haiku (for fastest, cheapest, simplest tasks).
• Parameter Tuning: Adjusting Temperature (0 for deterministic, 1 for creative) and defining termination conditions (Stop Sequences).
• System Prompts for Coding: Establishing clear rules for code style, language preference, and error handling.

Domain 4 — Structured data extraction (part of prompt engineering & structured output, 20%)

This is where prompt engineering meets validation engineering. The reliable pattern is a closed loop, not a one-shot prompt:

Alongside the loop, know the building blocks that feed into it: clear system prompts with XML-tagged structure for complex instructions, few-shot examples for format consistency, prefilling and format anchoring, and generation parameters (temperature, top_p, top_k) for controlling variance in extraction tasks. On the evaluation side — test datasets, automated grading, regression testing when you change a prompt.

Key Concepts to Master:

• XML Tagging for Input: Organizing messy data so Claude can distinguish between, for example, ’email body’ and ‘metadata.’
• Forcing Structured Output (JSON/XML): Using system prompts and specific output examples (Few-Shot Prompting) to instruct Claude to only return valid JSON, and nothing else.
• Validation: Strategies for immediately validating the generated structure (e.g., against a JSON Schema) before using it.

Domain 5 — Context management & reliability (15%)

The lightest-weighted domain but a frequent trap because it’s counter-intuitive: bigger context isn’t automatically better retrieval.

Key Concepts to Master:

• Token Efficiency: Understanding the trade-offs between including raw data, summaries, or metadata.
• Information Retrieval within Context: Techniques for organizing large prompts (e.g., using clear XML tags) so Claude can locate the needles in the haystack reliably.
• System Prompts: Using pre-computable system prompts for setting behavior rules.

The Optimal Learning Path

To build a resilient preparation strategy before launching your next consulting project out of Kolkata, focus on hands-on implementation:

• Complete the four foundational prerequisite courses on the Anthropic Partner Academy.
• Build a complete agentic loop using the Claude Agent SDK and integrate local MCP servers to solidify your understanding of tool discovery.
• Practice designing robust error-handling logic that intercepts tool failures and provides instructive recovery prompts rather than generic exceptions.

Sample Question 1: Context Management & Reliability

Scenario: A customer returns 4 hours after their initial session about the same billing dispute. The previous 32-turn session contains lookup_order results showing “Status: PENDING, Expected resolution: 24-48 hours”. In testing, you observe that when resuming sessions with stale tool results, the agent often references the outdated data in responses even after subsequent fresh tool calls return different information.

Question: What approach most reliably handles returning customers?

• A. Start a new session, inject a structured summary of the previous interaction (issue type, actions taken, resolution status), then make fresh tool calls before engaging.
• B. Resume with full history and add a system prompt instruction telling the agent to always prefer the most recent tool results.
• C. Resume with full history but filter out previous tool_result messages before resuming.
• D. Resume with full history and execute a preliminary script that forces tool invalidation for all cached order lookups.

Answer: A

Instructor’s Breakdown: LLMs struggle to disambiguate contradictory facts when both exist within the same context window. Resuming a long, 32-turn session not only risks hitting context limits, but also forces the model to weigh outdated tool returns against fresh ones. By starting a new session and injecting a structured summary, you provide the agent with a clean slate, preserving the narrative history without the technical debt of stale JSON payloads.

Sample Question 2: Structured Data Extraction

Scenario: Your extraction pipeline validates outputs against JSON schemas. Monitoring shows 12% of extractions fail Pydantic validation with specific errors like “expected float for quantity, got ‘2 to 3′”. Retrying these requests without modification produces identical failures.

Question: What is the most effective approach to recover from these validation failures?

• A. Implement a secondary pipeline using a larger model tier to reprocess documents that fail validation.
• B. Pre-process source documents to standardize problematic formats before sending them for extraction.
• C. Send a follow-up request including the validation error, asking the model to correct its output.
• D. Set temperature to 0 to eliminate output variability and ensure consistent formatting.

Answer: C

Instructor’s Breakdown: This highlights the “Retry-with-Error-Feedback” pattern. LLMs are highly capable of self-correction when provided with specific diagnostic data. Instead of building brittle pre-processing regex rules or falling back to more expensive models, simply passing the exact Pydantic validation error back to Claude allows it to instantly identify the formatting mismatch and generate a compliant schema on the next turn.

Sample Question 3: Claude Code Configuration & Guardrails

Scenario: Your team’s CLAUDE.md includes a rule: “Use 4-space indentation and always run Prettier formatting”. Despite this, code reviews reveal that roughly 30% of files Claude Code generates use inconsistent formatting. Adding emphasis (“IMPORTANT: You MUST use Prettier formatting”) reduces violations to about 15%, but does not eliminate them.

Question: What is the most effective way to ensure all generated code is consistently formatted?

• A. Configure a PostToolUse hook with an Edit|Write matcher that automatically runs Prettier on each file Claude modifies.
• B. Split the formatting rules into path-scoped .claude/rules/ files that load when Claude works on matching file types.
• C. Extract the formatting rules into a dedicated skill that Claude loads automatically when generating code.
• D. Enforce formatting only through pre-commit git hooks rather than involving Claude Code.

Answer: A

Instructor’s Breakdown: System prompts and markdown rules are guidelines, not guarantees. When a business or architectural rule cannot be left to model discretion, you must move it from the semantic layer (prompting) to the orchestration layer (code). Using a PostToolUse hook intercepts the action right after the tool executes, programmatically enforcing the standard without relying on the LLM’s instruction-following adherence.

Sample Question 4: Agentic Architecture & Orchestration

Scenario: A developer asks the agent to investigate why a specific API endpoint intermittently returns 500 errors. The codebase has 200+ files, and the developer doesn’t know which components are involved. The agent must trace the error through routing, middleware, business logic, and database layers.

Question: What task decomposition approach would be most effective?

• A. Have the agent first create a comprehensive plan mapping all code paths through the endpoint before beginning any file exploration or code reading.
• B. Have the agent dynamically generate investigation subtasks based on what it discovers at each step, adapting its exploration plan as new information about the error path emerges.
• C. Run parallel worker agents that simultaneously investigate all four layers, then synthesize their findings to identify where the error originates.
• D. Define a fixed sequence of investigation steps upfront—grep for error patterns, then read error handlers, then check database queries, then examine middleware—executing each step regardless of findings.

Answer: B Instructor’s Breakdown: This question tests the difference between rigid prompt chaining and dynamic workflows. For open-ended debugging tasks where the root cause is unknown, predefined sequential pipelines (Option D) or upfront comprehensive planning (Option A) fail because the agent cannot adapt to unpredictable discoveries. Dynamic adaptive decomposition allows the orchestrator to act as an investigator, letting the result of one tool call dictate the next logical subtask.

Sample Question 5: Tool Design & MCP Integration

Scenario: After integrating a local MCP server providing code analysis tools (analyze_dependencies, find_dead_code), you verify the server is healthy. However, you observe that the agent consistently uses the built-in Grep tool to search for import statements instead of calling analyze_dependencies—even when users explicitly ask about “code dependencies.”

Question: What is the most effective approach to improve the agent’s selection of MCP tools?

• A. Expand MCP tool descriptions to detail capabilities and outputs—e.g., “Builds dependency graph showing direct imports, transitive dependencies, and cycles.”
• B. Add routing instructions to the system prompt specifying that dependency-related questions should use MCP tools rather than Grep.
• C. Remove Grep from available tools when the MCP server is connected to eliminate functional overlap.
• D. Set tool_choice to require MCP tools on any prompt containing the word “dependencies”.

Answer: A Instructor’s Breakdown: The Model Context Protocol (MCP) relies heavily on semantic tool routing. When Claude faces overlapping capabilities (like text-searching for imports vs. generating a graph), it relies entirely on the descriptive naming and detailed schema definitions to make its selection. If an MCP tool description is vague, Claude will default to familiar, general-purpose tools like Grep. Expanding the description to explicitly highlight unique capabilities and examples is the most robust, scalable way to disambiguate tool overlap without hardcoding fragile system prompts.