CCAR-F Claude Code Configuration and Workflows Practice Question
A platform team maintains a shared monorepo. A developer runs Claude Code and wants the tool to automatically treat every file under `/infra/terraform/` as read-only for all engineers, without relying on each person to remember a flag. Where should this restriction be declared so it applies to everyone who opens the repo?
⚠ Common exam trap
The trap here is assuming that any file committed to the repo — including `.gitignore` or `CLAUDE.md` — can enforce a permission boundary, when only the settings file is mechanically evaluated.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
In the project's `.claude/settings.json` using a `permissions.deny` rule targeting the Terraform path.
Shared enforcement belongs in the committed project settings file, because it is version-controlled and applied to every session opened in that repository. A deny rule scoped to the Terraform directory stops edits deterministically, independent of individual developer setup. Per-user settings, Git ignore files, and memory documents all fail to give the team a uniform, repository-level guarantee that survives onboarding and local configuration drift.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
In the repo's `.gitignore` by adding the `/infra/terraform/` directory.
Why it's wrong here
`.gitignore` controls which untracked files Git will stage; it has no effect on Claude Code's file-editing permissions. In fact, ignoring a directory that is already tracked changes nothing about Git's behavior either. This is a version-control concern, not an agent permission boundary, so it does not prevent edits.
- ✗
In the `CLAUDE.md` memory file with a sentence asking Claude not to modify Terraform files.
Why it's wrong here
`CLAUDE.md` is contextual guidance that shapes behavior but is not an enforced permission boundary. A model instruction can be overridden by an explicit user request or drift under long context, whereas a deny rule is evaluated mechanically. For a hard guarantee across all engineers, memory text is the wrong layer.
- ✗
In each engineer's `~/.claude/settings.json` with a matching deny rule.
Why it's wrong here
User-scoped settings live in each person's home directory and are never shared through the repository. Even if the rule syntax is identical, a new hire or a developer who never copied the file would have no protection at all. The scenario explicitly requires a repo-wide guarantee, so a per-user file cannot satisfy it.
- ✓
In the project's `.claude/settings.json` using a `permissions.deny` rule targeting the Terraform path.
Why this is correct
Project-scoped `.claude/settings.json` is committed to the repo, so every engineer inherits the same permission rules automatically. A `permissions.deny` entry with a path-scoped pattern like `Edit(/infra/terraform/**)` blocks edits to those files regardless of who runs the session, which is exactly the shared, zero-effort enforcement the team wants.
About these practice questions
Courseiva writes every CCAR-F question from scratch — 271 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Anthropic exam blueprint
This CCAR-F practice question is part of Courseiva's free Anthropic certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CCAR-F exam.