CCA-F Study Guide: Domain-by-Domain Breakdown
You have decided to take the CCA-F. Good. Now the question is: where do you spend your study time?
The exam has five domains, each weighted differently. A naive approach would be to study them equally. A strategic approach allocates time proportional to weight and difficulty. This guide breaks down every domain so you know exactly what to focus on.
How to Use This Guide
For each domain, we cover four things:
- What it tests -- the specific knowledge and skills being evaluated
- Key concepts -- the ideas you must understand cold
- Common anti-patterns -- mistakes the exam expects you to recognize
- Study tips -- how to prepare efficiently
The domains are ordered by weight, from highest to lowest. If you are short on time, prioritize from the top.
Domain 1: Agentic AI Design Patterns (27%)
This is the heavyweight. More than a quarter of your score comes from this domain, and it is also the one where practical experience diverges most from best practices. Many developers build agents that work but are architecturally fragile. The exam tests whether you know the difference.
What It Tests
Your ability to design, evaluate, and troubleshoot agentic AI systems built with Claude. This includes understanding when to use agentic patterns at all, how to structure agent loops, and how to coordinate multiple agents.
Key Concepts
Agentic loops. The core perception-reasoning-action cycle. You need to understand how Claude processes observations, decides on actions, executes tools, and evaluates results. Know the difference between a single-turn tool call and a multi-turn agentic loop where the model iterates until a goal is met.
Multi-agent orchestration. Patterns for distributing work across specialized agents. The coordinator pattern (one agent delegates to specialists), the pipeline pattern (agents process sequentially), and the critic pattern (one agent reviews another''s output). Know when each is appropriate and when a single agent is sufficient.
Hooks. Pre- and post-processing hooks that run before or after agent actions. Hooks are the primary mechanism for enforcing guardrails, logging, and validation outside the model''s reasoning. This is a critical distinction -- hooks enforce rules deterministically, while prompts enforce them probabilistically.
Subagent isolation. Subagents do not share the coordinator''s memory or context by default. Each subagent gets only what the coordinator explicitly passes to it. This isolation is a feature, not a bug -- it prevents context contamination and makes the system more predictable.
Common Anti-Patterns
- Relying on prompts for safety enforcement. If a rule absolutely must be followed (no financial transactions over $10,000 without approval), enforce it with a hook, not a prompt. Prompts can be bypassed through creative phrasing or context overflow. Hooks cannot.
- Assuming subagents inherit coordinator context. They do not. If a subagent needs information from the coordinator, it must be explicitly passed. Code that assumes shared memory will fail silently.
- Building multi-agent systems when a single agent suffices. Multi-agent adds coordination overhead, latency, and debugging complexity. Use it when you need genuine specialization or parallel execution, not as a default architecture.
Study Tips
Build a simple agentic loop from scratch using the Claude API. Make it call a tool, evaluate the result, and decide whether to iterate or stop. Then extend it to a two-agent system where one agent delegates to another. The hands-on experience will make the exam scenarios intuitive.
If you get every question right in this domain and average 60% elsewhere, you still pass. If you bomb this domain, you need near-perfect scores everywhere else. Prioritize accordingly.
Domain 2: Tool Use and Integration (18%)
Tools are what make Claude useful beyond conversation. This domain tests whether you can design clean tool interfaces and handle the messy reality of tool execution.
What It Tests
Your ability to define tool schemas, integrate external services, handle errors gracefully, and choose the right integration pattern for a given use case.
Key Concepts
Tool schema design. Tools are defined with JSON schemas that specify name, description, and parameters. The description is critical -- it is how Claude decides when and how to use a tool. Vague descriptions lead to misuse. Overly narrow descriptions lead to underuse.
Model Context Protocol (MCP). The standardized protocol for connecting Claude to external tools and data sources. Know the architecture: MCP servers expose capabilities, MCP clients (like Claude Code) connect to them, and the protocol handles discovery, invocation, and response formatting.
Error handling. Tools fail. APIs time out. Data comes back malformed. The exam tests whether you know how to design tool integrations that degrade gracefully -- returning useful error messages to Claude rather than crashing the agent loop.
tool_use vs text-based output. When Claude needs to return structured data, the tool_use mechanism provides typed, validated output. Parsing structured data from text responses is fragile and error-prone. The exam will test whether you know when to use which.
Common Anti-Patterns
- Parsing structured data from text output. If you need JSON, use tool_use with a defined schema. Do not ask Claude to "output JSON" in a text response and then regex-parse it. It will break on edge cases.
- Ignoring tool errors. Silently swallowing a tool error and continuing execution leads to cascading failures. Always surface errors back to the model so it can reason about alternatives.
- Overloading tool descriptions. A tool that does five different things depending on parameters is hard for Claude to use correctly. Design narrow, focused tools with clear single purposes.
Study Tips
Read the MCP specification thoroughly. Build at least one MCP server and connect it to Claude Code. The exam questions on MCP tend to be specific about protocol details that you will only know from hands-on experience.
Domain 3: Claude Code and Developer Tooling (20%)
Claude Code is Anthropic''s CLI for Claude-powered development. If you have used it, this domain will feel familiar. If you have not, start using it immediately -- this is not something you can learn from documentation alone.
What It Tests
Your ability to configure Claude Code for a project, use it effectively in development workflows, and understand its operational model.
Key Concepts
CLAUDE.md. The project configuration file that provides Claude Code with context about your codebase. It includes project structure, conventions, tech stack, and specific instructions. A well-written CLAUDE.md dramatically improves Claude Code''s output quality. The exam tests whether you know what belongs in this file and how to structure it.
Slash commands and custom workflows. Claude Code supports custom commands defined in your project. Know how to create them, when to use them, and how they differ from system prompts.
Plan mode vs act mode. Plan mode lets Claude analyze and propose changes without executing them. Act mode executes changes directly. The exam tests your judgment about when to use each -- plan mode for complex refactors and unfamiliar codebases, act mode for well-understood, low-risk changes.
Context management. Claude Code operates within a context window. Long sessions accumulate context. You need to understand how to manage this -- when to start a new session, how to use compact mode, and how to structure requests to stay within token limits.
Common Anti-Patterns
- Neglecting CLAUDE.md. Working with Claude Code without a CLAUDE.md is like onboarding a new developer without documentation. The model will make assumptions that may be wrong.
- Using act mode on unfamiliar codebases. Always start with plan mode when you do not fully understand the implications of changes. Act mode is for execution, not exploration.
- Ignoring context window limits. Very long sessions degrade output quality as important context gets pushed out. Start fresh sessions for new tasks.
Study Tips
If you do not already use Claude Code daily, install it and use it for a week on a real project. Write a CLAUDE.md for the project. Create at least one custom command. Use both plan mode and act mode. The exam questions are practical -- they describe scenarios and ask what you would do.
Domain 4: Prompt Engineering and Structured Output (20%)
This domain is where most candidates feel overconfident. Everyone thinks they are good at prompting. The exam tests whether your prompting follows systematic best practices or just happens to work most of the time.
What It Tests
Your ability to write reliable, maintainable prompts that produce consistent output across diverse inputs.
Key Concepts
Explicit evaluation criteria. Instead of asking Claude to "write a good summary," specify what "good" means: length, tone, included elements, excluded elements. Explicit criteria make outputs consistent and evaluable.
Few-shot examples. Providing example input-output pairs in the prompt. Know how many examples to include (usually 2-5), how to select diverse examples that cover edge cases, and when few-shot is more effective than detailed instructions.
tool_use for structured output. When you need Claude to return data in a specific format, define a tool with the desired schema and ask Claude to use it. This gives you typed, validated output instead of hoping the model formats text correctly.
System prompt design. The system prompt sets Claude''s persona, constraints, and operating rules. Know the difference between system prompts and user prompts, how to structure multi-section system prompts, and what belongs at the system level vs the user level.
Common Anti-Patterns
- Using text-based JSON instead of tool_use. This is the number one mistake. If you need structured data, define a tool schema. Do not ask for JSON in a text response.
- Vague evaluation criteria. "Make it professional" is not a criterion. "Use formal tone, no contractions, third person, under 200 words" is a criterion.
- Too many or too few examples. Zero examples forces Claude to guess the format. Twenty examples wastes context. Find the sweet spot.
Study Tips
Take five prompts you use regularly and rewrite them with explicit criteria and tool_use output. Compare the consistency of results before and after. This exercise alone will prepare you for most Domain 4 questions.
Domain 5: Responsible AI and Production Readiness (15%)
The lightest domain by weight, but do not skip it. The questions here test judgment and operational thinking that many developers lack.
What It Tests
Your understanding of how to deploy Claude responsibly and manage it in production.
Key Concepts
Context management at scale. How to budget tokens across long conversations, when to summarize vs truncate, and how to maintain coherence as context accumulates. Production systems need strategies for this that go beyond "start a new conversation."
Escalation patterns. When the AI should stop and involve a human. Know the reversibility-consequence matrix: high-consequence, hard-to-reverse actions must escalate. Low-consequence, easily reversible actions can proceed autonomously.
Output provenance. Tracking where information came from. When Claude cites a source, how do you verify it? When Claude generates content, how do you distinguish it from human-written content? Production systems need provenance chains.
Content filtering and safety. Understanding Claude''s built-in safety measures, when to add additional layers, and how to handle edge cases where safety and utility conflict.
Common Anti-Patterns
- Silent error suppression. Catching an error and returning a default value without logging or alerting. In production, silent failures compound until the system is producing garbage output and nobody knows why.
- No escalation path. Systems with no mechanism for the AI to say "I am not confident enough to handle this" will eventually make a high-stakes mistake.
- Ignoring token costs. Production systems that do not monitor and budget token usage will surprise you with costs that scale faster than expected.
Study Tips
Review the responsible AI sections of Anthropic''s documentation. Think about your own production deployments -- where are the gaps in monitoring, escalation, and error handling? The exam questions often describe a production scenario and ask you to identify the missing safeguard.
Putting It All Together
Here is a time allocation guide based on domain weight and typical difficulty:
| Domain | Weight | Suggested Study Time |
|---|---|---|
| Agentic AI Design Patterns | 27% | 30% of total |
| Prompt Engineering and Structured Output | 20% | 20% of total |
| Claude Code and Developer Tooling | 20% | 20% of total |
| Tool Use and Integration | 18% | 18% of total |
| Responsible AI and Production Readiness | 15% | 12% of total |
The Agentic AI domain gets a disproportionate share because it is both the heaviest and the hardest. The Responsible AI domain gets slightly less than its weight because the concepts are more intuitive if you have production experience.
Ready to Start?
Our CCA-F exam prep course walks through every domain with hands-on exercises, practice questions, and scenario-based drills. It is the fastest path from "I should probably get certified" to exam day confidence.
Study smart. Study by domain weight. Pass on the first attempt.
Related Posts
Get AI Tips Every Week
Get smarter about AI every week — practical tips, prompts, and workflows in your inbox.