Claude Certification Blog
CCAR-P integration: eight objectives, 19% of the paper, two nobody expects
The largest domain on the Claude architect professional exam packs eight objectives into 12 items, and two of them are named nowhere else in the entire certification programme.
CCAR-P integration is the largest domain on that exam at 19% — about 12 of 63 items — and it carries eight published objectives, more than any other domain on the paper. Six of them cover ground an experienced architect will recognise: authentication and authorisation gaps, accuracy-latency trade-offs, observability, connection protocols and two on retrieval. The other two are the reason this domain deserves its own read.
Eight objectives, one domain
| Objective | The judgment it asks for |
|---|---|
| Capability bloat | Whether a tool or agent holds more than its work needs |
| Authentication and authorisation | Finding the gap rather than describing the scheme |
| Accuracy against latency | Justifying the configuration, not only choosing it |
| Observability at scale | What you can still diagnose once volume is real |
| RAG pipeline design | Chunking and indexing chosen for the data, not by default |
| Retrieval strategy | Matched to data shape and to how it is queried |
| Connection protocols | Selecting the mechanism the integration actually needs |
| Progressive discovery | Revealing context as required, or supplying it all at once |
Eight objectives across twelve items has a planning consequence worth stating plainly: most of these are worth one question. A domain with three objectives and the same weight rewards depth; this one rewards covering all eight at least once. Skipping the two least familiar to save time is exactly the wrong trade, because they are the two you cannot answer from experience.
Capability bloat
The objective is evaluating tool and agent configuration for capability bloat, and the underlying rule is short: a component should hold what its work requires and no more. An agent that never needs to delete anything should not have deletion available, because what is available is a stronger constraint than what is instructed.
There is a second effect the exam cares about, and it is not a security one. The more near-identical tools a model has to choose between, the less accurately it chooses, so a bloated configuration buys worse decisions as well as wider exposure. Both consequences follow from the same fix, which is why the option that trims the set beats the option that improves the descriptions. The contract side of that is covered in tool use and structured output, and the exposure side in prompt injection and guardrails.
Progressive discovery
An explicit objective on this track and on no other: evaluating progressive discovery against a monolithic context strategy. Supply everything up front and you pay for it on every request and dilute what matters among what might. Reveal as you go and each step is cheaper and sharper, at the cost of more round trips and a design that has to know what to fetch next.
The examinable judgment is which cost the described system can absorb. A latency commitment argues for having it already; a large corpus with a narrow query argues for fetching. Neither is the default answer, and an option that picks one without reference to the constraint in the scenario has skipped the question. The same trade shows up as a working problem in context management.
Two objectives, roughly two items, and no way to derive them
Capability bloat and progressive discovery are the two objectives on this domain you cannot answer from general architecture experience, because they are named judgments rather than familiar practice. They are also small — a couple of items. Twenty minutes each is the best-value time on this paper.
The two retrieval objectives
Designing a RAG pipeline with chunking and indexing strategies, and applying retrieval matched to data shape and query pattern. These make CCAR-P the only track where retrieval is examined under its own name — the associate and developer guides do not use the vocabulary at all.
What both objectives share is the word matched. The examinable failure is a default applied without reference to the material: a chunk size chosen because it is common, an index chosen because it is the one you have used. Where the data is long and the queries are narrow, or the data is short and the queries are broad, the right answer changes. Our post on RAG across the four tracks sets out where it is and is not examined.
Observability at scale
The objective adds two words that change it: at scale. Diagnosing one bad response is not the subject; being able to diagnose anything once volume is real is. That means deciding in advance what gets recorded, because the information you did not capture is not recoverable afterwards.
The recurring distractor is a monitoring answer that reports health rather than enabling diagnosis. A system can be entirely green and still give you nothing to work with when a specific answer was wrong, which is the situation the objective is written for.
Accuracy against latency
The objective asks you to evaluate the trade and justify the configuration decision, which is the operative half. A choice with no stated reason is not an answer here, and the reason has to reference something in the scenario rather than a general preference for quality or for speed.
This is also where the integration domain meets the commitments domain. A latency figure agreed with a stakeholder is a constraint on this decision, not a separate conversation — see stakeholder communication on CCAR-P, where the same number arrives from the other direction.
Key takeaways
- Nineteen percent, twelve items, eight objectives. The largest domain on CCAR-P and the one with the most ground to cover.
- Breadth beats depth here. Most objectives are worth about one item, so cover all eight rather than mastering three.
- Capability bloat is a named objective. Trimming the tool set fixes both selection accuracy and exposure at once.
- Progressive discovery appears on no other track. Which cost the system can absorb decides it, not a default preference.
- Retrieval answers turn on matching. Chunking and indexing chosen for the data and the query, never by habit.
- Observability means diagnosis, not health. An all-green system that cannot explain one wrong answer has failed the objective.
Twelve items is a fifth of the paper
A domain this broad is where an even study plan quietly fails: it is easy to cover six objectives, feel prepared, and meet the other two cold. Timed papers built to the published 63-item allocation put all eight in front of you. Our claude certification study guide covers how to sequence them.
See the CCAR-P blueprintQuestions
Frequently asked
The follow-up questions people search next.
What is the biggest domain on CCAR-P?
Integration, at 19% of the exam — about 12 of 63 items. It also carries eight objectives, more than any other domain on that paper, which means each one is worth roughly one or two questions.
What does capability bloat mean on the exam?
It is a named objective: evaluating tool and agent configuration for capability bloat. The judgment is whether a component holds more capability than its work requires. An agent that never needs a destructive action should not have one available, because availability is a stronger control than any instruction about restraint.
What is progressive discovery versus monolithic context?
Whether a system reveals context to the model as it becomes relevant, or supplies everything up front. It is an explicit CCAR-P objective and appears on no other track. The trade is between the cost and dilution of carrying everything and the extra round trips of fetching as you go.
Is RAG examined on the Claude exams?
By name, only on CCAR-P — two of this domain’s eight objectives cover designing a pipeline with chunking and indexing strategies, and matching retrieval to data shape and query pattern. The words retrieval, embedding and vector do not appear in the CCAO-F or CCDV-F guides at all.
How much time should this domain get?
Roughly a fifth of your plan, matching its weight, but split by objective rather than evenly. Eight objectives across 12 items means most get one question, so breadth beats depth here — unlike a domain with three objectives and the same weight.
Keep reading
Related posts
Not affiliated with, or endorsed by, Anthropic or Pearson VUE. Details are summarised from publicly published program information and can change — always confirm against the official exam guide before booking.