Anthropic CCA-F: 30-Day Study Plan
A 30-day plan can work for Claude Certified Architect – Foundations when you already have some software, cloud, AI, or architecture experience and use the month to close specific gaps. This schedule follows Anthropic’s five official domains, gives the largest share to agentic architecture, and requires practical design work so the month produces evidence of readiness rather than only completed reading.
On this page
- Before day 1: build a domain baseline
- Days 1–7: agentic architecture
- Days 8–13: tools and MCP
- Days 14–19: Claude Code
- Days 20–24: prompting and structured output
- Days 25–26: context and reliability
- Days 27–28: integrated architecture labs
- Day 29: mixed scenario review
- Day 30: final readiness and logistics
- Use a daily study routine that produces evidence
- Adjust the plan to your background
- Know when to extend the schedule
- 30-day plan summary
Before day 1: build a domain baseline
Start with Anthropic’s current Claude Certified Architect – Foundations blueprint and mark each objective area as strong, familiar, weak, or new. Do this before choosing a course sequence so the calendar reflects your actual experience.
Record whether you can explain the five domain weights from memory: Agentic Architecture & Orchestration 27%, Tool Design & MCP Integration 18%, Claude Code Configuration & Workflows 20%, Prompt Engineering & Structured Output 20%, and Context Management & Reliability 15%.
Run a small practical diagnostic. Sketch an agent workflow, design one tool schema, explain an MCP boundary, describe how Claude Code should be configured for a team repository, and outline how you would evaluate a structured-output application.
Your weakest explanations become the priorities for the month. The plan below uses the official weights as a default, but the diagnostic should move time toward genuine gaps.
Days 1–7: focus on Agentic Architecture & Orchestration
Spend the first week on the largest domain. Learn the architecture spectrum from direct model calls to deterministic workflows, tool-using agents, and multi-agent systems.
Practice choosing sequential, parallel, routing, evaluator-optimizer, and agent-loop patterns according to task uncertainty rather than novelty.
Use Agentic Architecture and Orchestration to study state handoffs, stop conditions, budgets, observability, tool authority, and human approval as one system.
End the week by drawing two architectures for the same business problem: one simple workflow and one more autonomous design. Explain what additional value would justify the extra complexity.
Days 8–13: learn Tool Design & MCP Integration
Begin with model-facing tool design. Write precise names and descriptions, narrow parameter schemas, explicit error states, and concise results for a small set of tools.
Then move into MCP Server Design and Integration. Distinguish tools, resources, and prompts, and decide how authentication, authorization, server boundaries, and context cost should be handled.
Build one safe MCP-style design on paper or in a nonproduction lab. Identify which external system it reaches, which identity it uses, what information is exposed, and which operations require approval.
Finish the block by explaining why discovery is not authorization and why a correctly structured tool can still be dangerous if its underlying permissions are too broad.
Days 14–19: study Claude Code Configuration & Workflows
Use Claude Code Configuration and Workflows as the Domain 3 anchor.
Practice project instructions, scoped rules, settings ownership, configuration precedence, permission modes, plan-first work, MCP connectivity, hooks, and large-repository context.
Create a small safe repository and document build commands, test commands, architecture boundaries, generated files, and risky operations. Then observe whether Claude Code follows the configuration consistently.
Change one rule or permission and retest the same task. The point is to learn how configuration changes behavior, not merely where configuration files are stored.
Days 20–24: study Prompt Engineering & Structured Output
Work through Prompt Engineering and Structured Outputs with emphasis on application contracts rather than prompt tricks.
Separate durable system guidance from user requests and untrusted retrieved data. Use examples only when they clarify a decision boundary that prose instructions do not express well.
Design a JSON response schema for a real consumer, then list the business rules the schema cannot enforce. Repeat the exercise with a strict tool schema.
Version the prompt and schema, run representative examples, and record semantic failures separately from structural failures. This is the architect-level connection between prompting and software contracts.
Days 25–26: connect Context Management & Reliability
Use Context Management and Reliability to review context budgets, retrieval, memory, compaction, prompt caching, latency, and evaluation.
Build a small context inventory for an agent: system guidance, tool definitions, recent conversation, retrieved evidence, durable state, and stale tool history. Decide what must remain, what can be summarized, and what belongs outside the prompt entirely.
Review prompt caching, memory, retrieval, latency, and evaluation as different controls rather than interchangeable optimization techniques.
Finish by describing a context failure you could observe in production and which telemetry or evaluation would show whether the fix actually helped.
Days 27–28: run integrated architecture labs
Combine the domains in two small scenarios. One can be a research or support agent; another can be a Claude Code workflow connected to an external system through MCP.
For each scenario, document architecture, model choice, tools, permissions, human approval, state, prompt contract, structured output, context strategy, evaluation, cost and latency expectations, and failure handling.
Introduce one failure deliberately: unavailable tool, malformed result, denied permission, stale retrieval, or context overflow. Explain how the architecture detects and recovers from it.
A strong lab produces a short design record rather than only screenshots. The exam rewards the reasoning that connects components and tradeoffs.
Day 29: switch to mixed scenario review
Use mixed questions or self-created cases that force several domains together. Avoid reviewing only one chapter at a time on the final practice day.
For every answer, state which domain is primary, which secondary domain is involved, what business objective matters, and why the closest alternative is weaker.
Review your error log for recurring patterns. If you consistently choose autonomous agents where a workflow would suffice, or confuse schema validation with authorization, revisit the underlying principle rather than memorizing one answer.
Keep final review focused on decisions and relationships. Product details can change; architecture principles and official domain intent are more durable.
Day 30: final readiness and logistics
Confirm that your Claude Partner Network access and current Academy eligibility are in place before exam day. Recheck the official credential page for current delivery details.
Review the five weights, your weakest notes, and the design distinctions that caused repeated mistakes. Do not spend the final day collecting a new course.
If using online proctoring, verify the required environment and equipment early enough to fix problems. If using a Pearson test center, confirm identification, travel, and appointment details.
Use the last study session for calm recall and explanation. A rested architect who can reason through unfamiliar scenarios is better prepared than one who added another list of facts overnight.
Use a daily routine that produces evidence, not passive completion
Divide most study sessions into three parts: learn one concept, apply it in a small design or lab, and explain the result without notes.
Keep one domain tracker and one error log. Scattered bookmarks and several overlapping note systems make it harder to see what is still weak.
Use spaced review across the month. Revisit architecture decisions from week one while studying tools, Claude Code, prompts, and context so the domains stay connected.
When a source describes a product feature, verify fast-moving details in current Anthropic documentation. Use the certification blueprint to decide whether the feature matters to the exam.
Adjust the 30-day plan to your background
An experienced application architect may move quickly through workflow patterns but need more hands-on Claude Code and MCP practice.
A Claude Code power user may already understand repository configuration yet need deeper system-level thinking about agent authority, evaluation, and reliability.
A prompt engineer may be comfortable with examples and output contracts but need more work on orchestration, authentication, tool permissions, and operational failure modes.
Reallocate days according to evidence. Domain weights matter, but they should not force you to spend equal effort on topics you already understand well.
Know when to extend the schedule instead of forcing the date
Thirty days is an intensive plan, not a guarantee. Extend it if you still need notes to explain the architecture patterns or cannot connect multiple domains in one scenario.
Unstable performance across different practice sources can indicate memorization rather than transferable understanding.
You should be able to design a safe tool or MCP boundary, explain Claude Code configuration choices, create a prompt/output contract, and diagnose a context or reliability issue without a script.
If those tasks remain uncertain, another week of targeted practice is more useful than repeatedly taking full practice exams without repairing the underlying gap.
30-day CCA-F study-plan summary
Use the official domain weights to structure the month, then adjust with a diagnostic so time follows your real gaps.
Spend the most time on agentic architecture, treat tools/MCP and Claude Code as architecture domains rather than product trivia, and connect prompts with machine contracts and evaluation.
Build at least two integrated labs that combine domains and include failure handling, authority, context, and observability.
The 30-day plan works when every week produces stronger explanations and better architecture decisions, not when it merely produces completed videos.