Skip to content
Cheat sheets

CCAR-F · Domain 3: Claude Code Configuration & Workflows · 20% of the exam

Task 3.6: Integrate Claude Code into CI/CD pipelines

Running Claude Code unattended with -p, machine-readable results with --output-format json and --json-schema, project context for CI runs through CLAUDE.md, independent review sessions, and re-reviews that report only new issues.

Study it

  • Claude Code in CI: -p, JSON output with a schema, and independent review runs

    Lesson coming

Sample questions

Try each one before opening the answer. Every option is explained, with the Anthropic documentation page that proves it.

Question 1 · choose 1

Your CI job runs Claude Code on each pull request and must turn its review findings into inline comments through the code host's API. The posting script needs to parse every result reliably, with a file, line, severity and message for each finding. How should the job invoke Claude Code?

  1. Aclaude -p with the default text output, and a regular expression in the script that extracts each finding
  2. Bclaude -p with --verbose text output, parsed line by line for findings
  3. Cclaude -p with a prompt that asks for JSON, and a retry in the script whenever parsing fails
  4. Dclaude -p with --output-format json and a --json-schema for the findings, read from structured_output
Show the answer and why

  • Aclaude -p with the default text output, and a regular expression in the script that extracts each finding

    Incorrect

    Free text changes shape between runs, so a regular expression breaks on findings it does not expect.

  • Bclaude -p with --verbose text output, parsed line by line for findings

    Incorrect

    Verbose text is meant for people; the script would still guess where each finding starts and ends.

  • Cclaude -p with a prompt that asks for JSON, and a retry in the script whenever parsing fails

    Incorrect

    Asking for JSON does not validate it; the script still has to handle malformed output and retries.

  • Dclaude -p with --output-format json and a --json-schema for the findings, read from structured_output

    Correct

    With a schema, print mode returns validated JSON in structured_output, which a script can post without guessing.

For machine-parseable CI output, combine -p with --output-format json and --json-schema. The result's structured_output field holds output that matches the schema, ready to post as inline comments.

Anthropic documentation

Task 3.6Report a problem with this question

Question 2 · choose 1

Your CI review job runs again on every new commit to a pull request. Each CI run starts on a fresh runner, and developers complain that every run re-posts the findings they already fixed or acknowledged. How should the job change?

  1. APass the previous run's findings in the prompt and ask only for new or still-unaddressed issues
  2. BDrop any new comment whose text exactly matches a comment already on the pull request
  3. CLower --max-turns for the later runs so that each review stops before it reaches code that was already reported
  4. DRun claude -p --continue so that the job resumes the previous review session and remembers its findings
Show the answer and why

  • APass the previous run's findings in the prompt and ask only for new or still-unaddressed issues

    Correct

    With the prior findings in context, Claude can compare them with the new commits and skip what was already reported or fixed.

  • BDrop any new comment whose text exactly matches a comment already on the pull request

    Incorrect

    Claude words findings differently from run to run, so exact matching lets most duplicates through.

  • CLower --max-turns for the later runs so that each review stops before it reaches code that was already reported

    Incorrect

    A turn limit cuts the review short at an arbitrary point instead of filtering what has been reported.

  • DRun claude -p --continue so that the job resumes the previous review session and remembers its findings

    Incorrect

    Each run starts on a fresh runner, so there is no earlier review session there to continue.

When re-running a review after new commits, include the earlier findings and ask for only new or still-unaddressed issues. Relying on local session state or text matching fails on ephemeral CI runners.

Anthropic documentation

Task 3.6Report a problem with this question

Question 3 · choose 1

A CI job runs claude -p to review each pull request's changes for risky patterns. Your organization's managed settings deny Bash outright, so Claude has no shell in these runs, and the prompt alone does not show Claude what changed. How should the job give Claude the diff?

  1. AAdd --dangerously-skip-permissions so that Claude can run git diff itself
  2. BPipe it in, as in git diff origin/main...HEAD | claude -p "...", so that Claude reads it from stdin
  3. CAdd --allowedTools "Bash(git diff *)" so that this one command is allowed
  4. DPass the changed file names and let Claude open them with Read, which the Bash deny does not block
Show the answer and why

  • AAdd --dangerously-skip-permissions so that Claude can run git diff itself

    Incorrect

    Deny rules block in every mode, including bypassPermissions, and a bare Bash deny removes the tool from Claude's context altogether.

  • BPipe it in, as in git diff origin/main...HEAD | claude -p "...", so that Claude reads it from stdin

    Correct

    Print mode reads stdin, and the job's own shell runs git, so Claude gets the diff without needing Bash permission.

  • CAdd --allowedTools "Bash(git diff *)" so that this one command is allowed

    Incorrect

    Deny rules are evaluated before allow rules, and an allow rule cannot carve an exception out of a deny rule.

  • DPass the changed file names and let Claude open them with Read, which the Bash deny does not block

    Incorrect

    The files' current contents do not show what the pull request changed, so the review cannot tell new code from old.

In print mode Claude Code reads stdin, so a CI script can run git itself and pipe the diff into claude -p. Claude works from the piped text and needs no tool permission to fetch it. When settings deny Bash, neither a permission mode nor an allow rule brings it back.

Anthropic documentation

Task 3.6Report a problem with this question

Question 4 · choose 1

Your team wants reviewers to ask Claude for help directly in a pull request comment, such as "suggest a fix for this edge case," and have it respond in that thread when asked, not on every push. What does the Claude Code GitHub Actions integration provide for this?

  1. AAn automation-mode workflow with a prompt that runs on every push
  2. Bclaude --from-pr, which each reviewer runs in a local terminal
  3. CA scheduled workflow that comments on open pull requests each night
  4. DAn interactive-mode workflow that answers @claude mentions in comments
Show the answer and why

  • AAn automation-mode workflow with a prompt that runs on every push

    Incorrect

    Automation mode runs without waiting for a mention, and by default its results go to the workflow log rather than the thread.

  • Bclaude --from-pr, which each reviewer runs in a local terminal

    Incorrect

    That opens local sessions linked to the pull request; it does not answer in the pull request thread.

  • CA scheduled workflow that comments on open pull requests each night

    Incorrect

    A schedule does not respond when a reviewer asks.

  • DAn interactive-mode workflow that answers @claude mentions in comments

    Correct

    Without a prompt input, the action waits for an @claude mention in a comment and posts its response on that issue or pull request.

In interactive mode, the Claude Code GitHub Action responds when someone mentions @claude in an issue or pull request comment, and its progress and results appear as a comment there.

Anthropic documentation

Task 3.6Report a problem with this question

Question 5 · choose 1

A CI step sometimes keeps working for dozens of agentic turns on a hard pull request. You want each run to stop after a fixed number of turns, with an error you can detect. Which flag does that?

  1. A--max-turns, which errors out at the limit
  2. B--continue, which resumes the turn count of the last run
  3. C--output-format json, which limits turns to one
  4. D--verbose, which reports each turn as it runs
Show the answer and why

  • A--max-turns, which errors out at the limit

    Correct

    --max-turns caps agentic turns and reports the limit as an error.

  • B--continue, which resumes the turn count of the last run

    Incorrect

    --continue resumes a conversation; it does not cap turns.

  • C--output-format json, which limits turns to one

    Incorrect

    Output format does not limit turns.

  • D--verbose, which reports each turn as it runs

    Incorrect

    Verbose output shows more detail but does not stop the run.

In print mode, --max-turns limits agentic turns and exits with an error when the limit is reached.

Anthropic documentation

Task 3.6Report a problem with this question

Question 6 · choose 1

Only in CI, you want Claude Code to add a rule: "Report findings, never push commits." Developers' interactive sessions should not see it. How should the CI job add it?

  1. AAdd it to every developer's ~/.claude/CLAUDE.md
  2. BPut it in the pull request description
  3. CThe --append-system-prompt flag in the CI job
  4. DAdd it to the project CLAUDE.md
Show the answer and why

  • AAdd it to every developer's ~/.claude/CLAUDE.md

    Incorrect

    That changes developers' sessions, which is the opposite of the goal.

  • BPut it in the pull request description

    Incorrect

    A PR description is not an instruction channel for the run.

  • CThe --append-system-prompt flag in the CI job

    Correct

    The flag appends text to the system prompt for that run only.

  • DAdd it to the project CLAUDE.md

    Incorrect

    That applies to every session, interactive ones included.

--append-system-prompt (or --append-system-prompt-file) adds run-specific instructions, which suits scripts and CI.

Anthropic documentation

Task 3.6Report a problem with this question

Question 7 · choose 2

You are adding the Claude Code GitHub Action to the 20 repositories of your organization. Only maintainers should be able to trigger runs, and a leaked credential must not expose anything beyond what the workflows need. Which TWO practices follow the integration's guidance? (Choose TWO.)

  1. AUse one team member's subscription OAuth token as the organization-level secret for all repositories
  2. BStore a Claude Console API key as an organization-level Actions secret and reference it from the workflows
  3. CGrant each workflow only the permissions it needs
  4. DSet allowed_non_write_users so that anyone who comments can trigger a review
  5. EList the repositories' bot accounts in allowed_bots so that Claude's comments can trigger follow-up runs
Show the answer and why

  • AUse one team member's subscription OAuth token as the organization-level secret for all repositories

    Incorrect

    An OAuth token is tied to the subscription of the person who created it; a shared secret should be an API key from the Claude Console.

  • BStore a Claude Console API key as an organization-level Actions secret and reference it from the workflows

    Correct

    Keys belong in secrets, and an organization-level secret saves each repository from holding its own copy.

  • CGrant each workflow only the permissions it needs

    Correct

    Least privilege limits what an automated run, or a leaked credential, can change.

  • DSet allowed_non_write_users so that anyone who comments can trigger a review

    Incorrect

    That lets users without write access trigger runs, which the maintainers-only requirement rules out.

  • EList the repositories' bot accounts in allowed_bots so that Claude's comments can trigger follow-up runs

    Incorrect

    The bot check exists to keep bots from triggering Claude in a loop.

Keep the credential in a secret (for many repositories, an organization-level secret holding a Console API key), give workflows only the permissions they need, and keep the built-in checks on who can trigger runs.

Anthropic documentation

Task 3.6Report a problem with this question

Practise domain 3 →Practise all domains →