Production Automation & Cost Optimization•20% of Exam Score
Claude Code in CI/CD & Batch APIs
Integrating LLMs into automated GitHub Actions, GitLab CI, and batch processing pipelines requires architectural discipline regarding timeouts, cost predictability, and non-interactive execution.
Exam Syllabus Deep Dive
Core Architectural Principles Tested
Topic 1
Non-Interactive Execution (`--print`)
Interactive CLIs block CI/CD runners indefinitely waiting for terminal user input.
Architectural Best Practice:Always run Claude Code with `--print` or non-interactive flags alongside pre-configured system instructions.
Topic 2
Anthropic Message Batches API (50% Cost Savings)
Nightly code reviews, vulnerability scans, and large-scale migrations don't require immediate sub-second latency.
Architectural Best Practice:Dispatch non-urgent asynchronous workloads via the Message Batches API to receive a guaranteed 50% pricing discount with 24-hour turnaround.
Topic 3
Multi-Pass Architecture Review
Single-pass reviews often miss subtle edge-case interactions across large diffs.
Architectural Best Practice:Use a two-pass pipeline: Pass 1 identifies affected modules and interfaces; Pass 2 performs deep semantic and security analysis.
High-Yield Exam Rules to Remember:
- Async batch workloads should always use the Message Batches API for 50% cost reductions.
- CI pipelines must specify deterministic exit codes and strict execution timeouts.
- Always execute automated tests to validate agent code changes before committing.
Interactive Practice
Sample Questions from this Domain (18 Total)
Sample Question #1 (Q#10)Claude Code for Continuous Integration
Situation Context:A pipeline runs `claude "Analyze this pull request for security issues"`, but hangs waiting for interactive input.
What is the correct approach?
AUse the `-p` flag: `claude -p "Analyze this pull request for security issues"`
BSet `CLAUDE_HEADLESS=true`
CRedirect stdin from `/dev/null`
DUse `--batch`
Explanation & Architectural Rationale:`-p` (or `--print`) is the documented way to run Claude Code in non-interactive mode. It processes the prompt, prints to stdout, and exits. The other options are either non-existent features or Unix workarounds.
Sample Question #2 (Q#11)Claude Code for Continuous Integration
Situation Context:The team wants to reduce API cost for automated analysis. Claude currently serves two workflows in real time: (1) a blocking pre-merge check that must complete before developers can merge a PR, and (2) a tech-debt report generated overnight for morning review. A manager proposes moving both to the Message Batches API to save 50%.
How should you evaluate this proposal?
AUse batch processing only for tech-debt reports; keep real-time calls for pre-merge checks
BMove both workflows to batch processing and poll for completion
CKeep real-time calls for both to avoid ordering issues in batch results
DMove both to batch processing with a fallback to real time if a batch takes too long
Explanation & Architectural Rationale:The Message Batches API saves 50%, but processing time can be up to 24 hours with no guaranteed latency SLA. That makes it unsuitable for blocking pre-merge checks where developers are waiting, but ideal for overnight batch workloads like tech-debt reports.
Sample Question #3 (Q#12)Multi-file Code Review
Situation Context:A pull request changes 14 files in an inventory tracking module. A single-pass review of all files produces inconsistent results: detailed comments for some files but superficial ones for others, missed obvious bugs, and contradictory feedback (a pattern is flagged as problematic in one file but approved in identical code in another file).
How should you restructure the review?
ASplit into focused passes: analyze each file individually for local issues, then run a separate integration pass for cross-file data flows
BRequire developers to split large PRs into submissions of 3–4 files
CSwitch to a higher-tier model with a larger context window to review all 14 files in one pass
DRun three independent full-PR review passes and report only issues found in at least two runs
Explanation & Architectural Rationale:Focused passes directly address the root cause—attention dilution when processing many files at once. Per-file analysis ensures consistent depth, and a separate integration pass catches cross-file issues. B shifts burden to developers without improving the system. C is a misconception: larger context does not fix attention quality. D suppresses real bugs by requiring consensus across inconsistent detections.