CLAUDE.md and settings.json for the Developer Exam

The two files that configure Claude Code

Configuration management is how you make a Claude system behave consistently and deliberately instead of by ad-hoc habit. In Claude Code, two files carry most of that weight, and the Claude Certified Developer - Foundations (CCDV-F) exam expects you to know what each one is for. CLAUDE.md encodes the standards and instructions you want the agent to work to. settings.json encodes operational behavior such as what the agent is permitted to do, which tools are available, and which hooks fire. Task Statement 2.6, Configuration Management, treats this at understand level, so the aim is to reason about what belongs where, not to memorise every key.

This knowledge point builds on how Claude interprets instructions across interfaces, because CLAUDE.md is precisely a mechanism for getting standing instructions into the Claude Code interface's context. It also anchors the rest of Task Statement 2.6: model version pinning and prompt versioning and plugin dependencies both build on the idea that configuration is explicit, shared, and version-controlled.

CLAUDE.md: standards loaded as context

CLAUDE.md is where a project's standards live in a form the agent can actually use. It captures the conventions, architecture notes, coding rules, and behavioral guidance you want in force, and Claude Code loads it as context at the start of a session. Because it is loaded automatically, the agent begins each session already aware of how this project expects work to be done, without anyone re-pasting the same guidance every time.

The mental model that matters for the exam is that CLAUDE.md is instructions-as-context. It is not code the system executes and not a hidden setting the runtime obeys; it is text the model reads, the same category of input as a system prompt, delivered through a file convention. That is exactly why the second core concept matters so much: because CLAUDE.md is a Claude Code convention, a raw call to the Claude API does not read it. The API sees only the messages and system prompt your code sends. If your standards need to reach a raw API integration, you have to include them in what you send; you cannot rely on CLAUDE.md, which only Claude Code loads.

settings.json: operational behavior

Where CLAUDE.md shapes what the agent knows, settings.json shapes what the agent is allowed and configured to do. It is the operational configuration file: permissions that govern which actions are allowed, tools that are available, hooks that run at defined points, and other behavioral settings. If CLAUDE.md is the project's playbook, settings.json is its operational policy.

The distinction is worth holding cleanly because the two files answer different questions. CLAUDE.md answers "what standards should guide the work," and it does so as context the model reasons over. settings.json answers "what is this agent permitted to do and how is it wired up," and it does so as configuration the runtime enforces. A permission the model should not be able to bypass belongs in settings.json, not in a politely worded line of CLAUDE.md, because one is enforced by the harness and the other is guidance the model interprets.

Project level versus user level

The third core concept is placement. Both files can exist at more than one level, but shared team standards belong at the project level, where they are committed to version control and travel with the repository, rather than being kept per user. Project-level configuration is shared: every developer who checks out the repo gets the same CLAUDE.md and the same settings.json, so the whole team works to the same standards and the same operational policy.

User-level configuration, by contrast, is personal to one developer's machine and does not travel with the project. That makes it the wrong home for anything the team needs to agree on. If a coding standard, a required permission policy, or a project convention lives only in one person's user configuration, it is invisible to everyone else and vanishes the moment someone else does the work. The exam wants you to place shared standards in project-level, version-controlled configuration so they are consistent across the team and auditable through the repository's history.

What the exam tests you on

This knowledge point sits in Domain 2, Applications and Integration, the highest-weighted domain on the CCDV-F exam at roughly 33 percent, and it is assessed at understand level. Two traps recur.

The first trap is putting shared team standards in user-level configuration instead of project-level. A standard that everyone must follow but lives only on one developer's machine is not really a team standard at all, because no one else sees it and it is not under version control. The correct placement is project-level, so the configuration is shared and auditable.

The second trap is assuming raw API calls read CLAUDE.md. They do not. CLAUDE.md is a Claude Code convention, so a direct integration against the Claude API sees only the messages and system prompt it is sent. Standards that must reach a raw API path have to be included explicitly in the request; expecting CLAUDE.md to apply there is a configuration error.

Worked example

How it shows up on the exam

Questions tend to probe placement and scope. A scenario where a standard is not being applied across the team is testing whether you catch configuration stranded at the user level. A scenario where a raw API integration ignores project conventions is testing whether you remember that CLAUDE.md is a Claude Code convention the API does not read. Keep the three anchors straight, CLAUDE.md for standards-as-context, settings.json for operational behavior, and project-level for anything shared, and the questions resolve cleanly.

From here, configuration management extends to keeping the model and prompts stable, covered in model version pinning, and to versioning prompts and dependencies into coherent releases, covered in prompt versioning and plugin dependencies.