Claude Certified Architect — Foundations (CCA-F) Thumb Rules Cheat Sheet: Domains 1–3

Compiled while prepping for the CCA-F exam. Sharing in case it helps other practitioners.

The One Meta-Rule That Runs Through Everything

Nothing happens automatically unless you explicitly build it. No auto-shared context between subagents. No auto-refresh on session resume. No auto-enforcement from a prompt, no matter how emphatically worded.

Whenever a question describes unexpected/inconsistent behavior, ask: “What did I assume was automatic that actually needed to be wired up explicitly?”

Domain 1: Agentic Architecture & Orchestration (27%)

1. Loop control: Use stop_reason (“tool_use” = continue, “end_turn” = stop). Never infer completion from parsed text or arbitrary iteration caps.
2. Streaming nuance: stop_reason is null at message_start — it’s only populated in message_delta, once the turn concludes.
3. Subagent context is isolated. No shared memory, no common session ID magic. The coordinator must explicitly pass prior findings into each subagent’s prompt.
4. Delegation needs explicit config. If a coordinator won’t invoke subagents, check that allowedTools includes “Task” before assuming a prompt/design issue.
5. Fixed sequence → prompt chain. Variable/query-dependent sequence → dynamic decomposition. Don’t over-engineer a linear 3-step pipeline with runtime decision-making it doesn’t need.
6. Independent subagent tasks → parallel Task calls. Only go sequential when one subagent’s output actually feeds the next.
7. fork_session = branching one session into divergent, isolated exploration paths from a shared starting point — not for resuming, not for subagent delegation.
8. Scope creep mid-task → structured handoff, never a silent guess. A subagent hitting an out-of-scope issue should escalate with context, not decide unilaterally or drop it silently.
9. Multi-concern requests: decompose → investigate in parallel with shared context → synthesize one unified response. Never make the customer split their own request.
10. Hard business rules (refund limits, compliance thresholds) → hooks, not prompts. Any non-zero bypass rate on a “must never” rule means enforcement needs to move server-side.

Domain 2: Tool Design & MCP Integration (18%)

1. Tool descriptions are a prompting surface, not documentation. Auto-generated API docs with vague params (param1, flag_b) will cause misuse — write for a smart newcomer with zero institutional context.
2. Granularity is a Goldilocks problem. Too many narrow tools (one per field) → decision paralysis. One mega-tool with free-text parsing → hides capability from reasoning. Group by operation type, parameterize by scope.
3. Errors are also a prompting surface. “400 Bad Request” gives Claude nothing to act on. Tell it what failed and what to try instead.
4. Empty/ambiguous results are worse than explicit errors. Silence forces Claude to guess; guessing is a silent-failure pattern the exam always marks wrong.
5. Unstructured tool results = guessed relevance. Rank/structure results (not just dump raw text) so Claude can tell strong matches from weak ones.
6. Security boundaries at the tool/server layer → enforce server-side (path allowlists), never rely on the model’s judgment or a prompt instruction.

Domain 3: Claude Code Configuration & Workflows (20%)

1. Three configuration axes — know which one a scenario is testing:

• Always vs. on-demand → CLAUDE.md (every session) vs. slash commands (invoked when needed)
• Suggested vs. enforced → prompts/CLAUDE.md notes (probabilistic) vs. hooks/settings.json (deterministic)
• Shared vs. individual → project CLAUDE.md (team-wide facts) vs. personal/user settings (individual preference, e.g. verbosity)

1. CLAUDE.md is for permanent, universal, project-level truth — coding standards, architecture notes. Never put one-off/task-specific instructions there; they’ll haunt every future session.
2. Allow/deny lists need pattern matching, not exact strings. Exact-match allowlists break on trivial variations (npm test vs npm test — watch) and cause inconsistent, confusing approval behavior.
3. Denylist blocking is fragile — prefer allowlists for destructive-action prevention. Blocking one string (rm -rf) doesn’t stop equivalent destructive commands (find . -delete). Allow known-safe patterns instead of trying to enumerate every dangerous one.
4. PostToolUse hooks aren’t just for blocking — they’re equally valid for automated follow-up (linting, formatting, running tests) that should happen consistently without relying on human memory.
5. A hook that blocks should route to an escalation path, not a dead end. Blanket blocks on legitimate operations (e.g., all .env writes) create workaround pressure. Distinguish risky sub-actions from safe ones, or add human approval as a fallback.

Prepping for CCA-F myself — sharing these as I go. Feel free to add your own in the comments if you’re studying too.