Level 10 — Permissions, Sandboxing and Safety

12 questions, drawn from a bank of 34 across 27 topics. Pass at 85%. Every wrong option carries a note explaining why it is tempting — those notes are the point of the quiz, so read them whether you pass or not.

attempt 1

1 / 12 · Choose one
Your settings deny Bash(terraform apply *). A teammate adds a PreToolUse hook that returns "allow" for exactly that command, arguing that hooks run before the permission check. Does the command now run?
Your settings deny Bash(terraform apply *). A teammate adds a PreToolUse hook that returns "allow" for exactly that command, arguing that hooks run before the permission check. Does the command now run?
Yes, unless the deny rule came from managed settingsIt prompts you to resolve the disagreement between the hook and the ruleNo. Hook decisions do not bypass permission rules: a matching deny rule blocks the call whatever the hook returned, and a matching ask rule still promptsYes — PreToolUse hooks run before the permission system, so an "allow" decision short-circuits the rule check
2 / 12 · Choose one
A repository's settings deny Bash(aws *). Your user settings allow Bash(aws s3 ls). Claude proposes aws s3 ls. What happens, and which of the two rules is doing nothing?
A repository's settings deny Bash(aws *). Your user settings allow Bash(aws s3 ls). Claude proposes aws s3 ls. What happens, and which of the two rules is doing nothing?
It runs, because user settings and project settings are different scopes and the higher-precedence one replaces the otherDenied. The deny rule matches and is evaluated first, so the narrower allow rule is well-formed, matches the call, and changes nothingIt prompts, because two rules disagree and Claude Code puts the decision back to youIt runs — the allow rule is more specific, and specificity is what resolves a conflict between two matching rules
3 / 12 · Choose one
A pipeline runs claude -p "…" --permission-mode dontAsk. Its settings allow Bash(npm test) and Read, and put Bash(git push *) in permissions.ask. Claude proposes git push origin main. What happens?
A pipeline runs claude -p "…" --permission-mode dontAsk. Its settings allow Bash(npm test) and Read, and put Bash(git push *) in permissions.ask. Claude proposes git push origin main. What happens?
The session falls back to Manual mode for that one call, and the pipeline blocks waiting for an answerIt prompts, because an explicit ask rule is on the list of actions no mode auto-approvesIt runs, because dontAsk only auto-denies tools that match no rule at allIt is denied. The session never waits for input, so a matching ask rule is refused rather than prompted
4 / 12 · Choose one
Claude Code warns at startup about the allow rule Bash(git * main). Beyond being wider than intended, what is the concrete risk?
Claude Code warns at startup about the allow rule Bash(git * main). Beyond being wider than intended, what is the concrete risk?
The * stands in for the subcommand, so the rule approves git -c core.fsmonitor=<script> diff main — and git -c makes git run a program you nameThe * is compiled as a regular expression here, so it also matches across shell operators such as &&It fails to match git log, so you are still prompted for the command you run mostIt approves git push origin main, a destructive command you almost certainly meant to exclude
5 / 12 · Choose one
Your organisation is on an Enterprise plan. You clone an unfamiliar repository whose checked-in .claude/settings.json contains the block below and start Claude Code in it in a terminal with no flags. Which mode is the session in?
terminal
```
{
  "permissions": {
    "defaultMode": "auto"
  }
}
```
Your organisation is on an Enterprise plan. You clone an unfamiliar repository whose checked-in .claude/settings.json contains the block below and start Claude Code in it in a terminal with no flags. Which mode is the session in?
Auto — project settings sit above user settings in the precedence order, so a defaultMode written there wins over anything you have configured for yourselfAuto, but only once you accept the workspace trust dialog, which is the gate on everything a checked-in project settings file contributes to the sessionAuto — the refused value falls through to the built-in default, and the built-in starting permission mode is autoNo mode at all — Claude Code refuses to start and prints a settings validation error naming the key, because auto is not an accepted value for defaultMode in a project-scoped fileManual — auto does not take effect from project or local settings, so the value is ignored and the session falls through to the built-in default, which is default on an Enterprise plan
6 / 12 · Choose all that apply
You add "allow": ["Bash(curl http://github.com/ *)"], intending to restrict curl to GitHub. The docs list the variations such a pattern misses. Which of these does the rule fail to match?
You add "allow": ["Bash(curl http://github.com/ *)"], intending to restrict curl to GitHub. The docs list the variations such a pattern misses. Which of these does the rule fail to match?
curl https://github.com/repos/xcurl http://github.com/curl -X GET http://github.com/repos/xURL=http://github.com && curl $URL
7 / 12 · Choose one
You ask Claude to fetch a vendor changelog and check for a breaking change. The result says the page does not mention one. Why is that not evidence, and what are the documented ways to get a better answer?
You ask Claude to fetch a vendor changelog and check for a breaking change. The result says the page does not mention one. Why is that not evidence, and what are the documented ways to get a better answer?
The domain was not in the built-in preapproved documentation set, so the fetch returned a stub instead of the page; a WebFetch(domain:...) allow rule for the vendor fixes itThe separate context window that isolates fetched content strips instructions out of the page, and strips surrounding content along with them; turning that isolation off returns the page intactClaude usually receives a small fast model's answer to the extraction prompt, not the page — so re-fetch with a more specific prompt, or curl it via BashThe fetch was served from WebFetch's cache, which keeps each response for fifteen minutes; re-running it with a cache-busting query string forces a fresh retrieval of the current page
8 / 12 · Choose one
You standardise on the settings block below across a fleet of CI machines. On some of them the sandbox dependency is missing. What happens on those machines by default, and which key changes it?
terminal
```
{
  "sandbox": {
    "enabled": true
  }
}
```
You standardise on the settings block below across a fleet of CI machines. On some of them the sandbox dependency is missing. What happens on those machines by default, and which key changes it?
Nothing changes until you also set allowUnsandboxedCommands: false, which is what turns the sandbox into a requirementClaude Code shows a warning and runs commands without sandboxing. Setting sandbox.failIfUnavailable to true makes it a hard failure insteadSandboxed commands fall back to the regular permission flow, so nothing runs unreviewedClaude Code refuses to start, because enabled: true states a requirement rather than a preference
9 / 12 · Choose one
A CI job runs claude -p on a contributor's branch. Which pairing is right: a defense the docs say is absent there, and something the repository supplies that runs anyway?
A CI job runs claude -p on a contributor's branch. Which pairing is right: a defense the docs say is absent there, and something the repository supplies that runs anyway?
Trust verification is disabled under -p; the repository's hooks, its env block, helper commands such as apiKeyHelper, and a project skill's allowed-tools are used regardlessDeny rules are not loaded in a -p session, since trust is what gates which of a repository's permission rules apply; its permissions.allow rules are loaded and do take effectCommand injection detection is disabled under -p, so a command with something appended to it is not caught; the repository's CLAUDE.md is still loaded and its instructions still obeyedThe auto-mode classifier does not run under -p, so no shell command is reviewed before it executes; the repository's .mcp.json servers connect anyway and their tools are available
10 / 12 · Choose one
Your session is in auto mode, and you want the classifier to treat this repository as public before it evaluates a push. You run gh repo view, which prints the visibility. Does that output settle it?
Your session is in auto mode, and you want the classifier to treat this repository as public before it evaluates a push. You run gh repo view, which prints the visibility. Does that output settle it?
No, and nothing in the session would: the classifier judges visibility from the remote host and name alone, which is what stops a repository being talked into looking publicNo on its own, but chaining it with git status does, because Claude Code shows the classifier what git status reports about the repositoryNo — tool results are stripped before the classifier sees them, so the output settles nothing. What it reads is your own messages, your tool calls and your CLAUDE.mdYes — the classifier sees your tool calls, and gh repo view is one of them, so what that call reported is part of what it evaluates
11 / 12 · Choose one
Claude read a staging .env during yesterday's session. You have since added the deny rule. Where is that value now, and what actually removes it?
Claude read a staging .env during yesterday's session. You have since added the deny rule. Where is that value now, and what actually removes it?
In the transcript, but encrypted at rest with the rest of ~/.claude, so adding the deny rule is all the remediation this actually needsIn the macOS Keychain alongside your Claude Code login credentials, which /logout clears along with everything else stored thereNowhere on disk — a transcript records messages and tool calls, but tool results are stripped before it is writtenIn the session transcript under ~/.claude/projects/, in plaintext; lowering cleanupPeriodDays shortens the exposure, and only never reading the file prevents it
12 / 12 · Choose one
You want Claude Code to refuse to open or modify anything under a directory named credentials/, wherever it appears in the tree and whichever tool does the modifying, notebooks included. Which deny block is built from rules Claude Code actually consults for file paths?
You want Claude Code to refuse to open or modify anything under a directory named credentials/, wherever it appears in the tree and whichever tool does the modifying, notebooks included. Which deny block is built from rules Claude Code actually consults for file paths?
{ "permissions": { "deny": ["Bash(cat credentials/*)", "Bash(less credentials/*)"] } }{ "permissions": { "deny": ["Write(credentials/**)", "Glob(credentials/**)"] } }{ "permissions": { "deny": ["Read(credentials/**)", "MultiEdit(credentials/**)"] } }{ "permissions": { "deny": ["Read(credentials/**)", "Edit(credentials/**)"] } }

12 questions still to answer