Free CCAR-F practice questions

The Resolution Desk team runs a Customer Support Resolution Agent on the Claude Agent SDK, calling the MCP tools get_customer, lookup_order, process_refund and escalate_to_human. To stop refunds being issued against unverified orders, they added a line to the project CLAUDE.md stating that process_refund must be called only after a successful lookup_order in the same session. Across the next 5,000 sessions, telemetry records 62 sessions in which process_refund was called with no preceding lookup_order call. Which statement best explains that residual failure rate?

• ACLAUDE.md is prompt based guidance that shifts the probability of a behaviour rather than controlling it, so compliance is statistical; a prerequisite that must hold every time needs a PreToolUse hook that inspects the call and blocks it.check_circle Correct
• BCLAUDE.md is loaded once at session start, so its text is evicted from the context window as the conversation grows and the constraint stops applying part way through longer disputes.
• CTool call ordering is enforced by the MCP server that publishes the tools, so the 62 sessions indicate that the server lost its per session state and stopped rejecting the out of order calls.
• DThe rule sits at the wrong level of the CLAUDE.md hierarchy, and moving it from the project file to a user level file would make the same wording binding on every session the team runs.

Why A is correct: Correct: instructions in context influence sampling and cannot bound it, whereas a PreToolUse hook runs outside the model and can deny the call deterministically before it reaches the tool.

Why B is wrong: Tempting because attention dilution over long conversations is a real effect, but the failure does not depend on eviction: the instruction is advisory even while fully present in context, so restoring it would not make the ordering binding.

Why C is wrong: Tempting because MCP servers do hold connection state, but the protocol exposes independent tools with no cross tool ordering semantics, so there is no server side sequencing rule that could have lapsed.

Why D is wrong: Tempting because the hierarchy is real and does change which sessions see a file, but scope is not enforcement: the same sentence read from any level remains guidance the model may decline to follow.

On the same Customer Support Resolution Agent, a coordinator session has already called get_customer and holds the customer record, a disputed amount of 149.00 and three prior contact notes in its conversation. It then dispatches a subagent with the Task tool, using the prompt "Reconcile this billing dispute and recommend a refund amount". The subagent's first action is a get_customer call it cannot populate, after which it returns a request for the customer identifier. Which mechanism explains that outcome?

• AA subagent inherits the coordinator's conversation but not its tool results, so the record was available to it as a summary line while the raw get_customer payload had already been stripped out.
• BA subagent runs in a separate context window and receives only the prompt text it was dispatched with, so the customer record the coordinator was holding was never visible to it at any point.check_circle Correct
• CThe Task tool passes the parent conversation by reference, and that reference went stale when the coordinator carried on working, leaving the subagent holding a handle it could no longer resolve.
• DThe subagent definition omitted get_customer from its allowedTools list, so the call was denied and the subagent read that denial as evidence that the customer identifier had gone missing.

Why A is wrong: Tempting because partial inheritance sounds like a sensible cost saving, but no part of the coordinator's conversation is carried across, so there is no summary line for the subagent to read.

Why B is correct: Correct: context isolation is the defining property of a dispatched subagent, so anything it needs must travel in the prompt rather than being assumed from the coordinator's conversation.

Why C is wrong: Tempting because a stale handle would produce exactly this symptom, but there is no reference passing mechanism of this kind; the subagent is given text, not a pointer to the parent conversation.

Why D is wrong: Tempting because allowedTools genuinely restricts a subagent, but a denied call surfaces as an error rather than as a missing argument, and an excluded tool would not have been available to call in the first place.

The Resolution Desk team bounds cost on their Customer Support Resolution Agent by stopping the harness after 12 model calls per session. A billing dispute session hits that ceiling with the refund unissued and no message sent to the customer, and the on call engineer argues that the ceiling is what ends a healthy session as well. Which statement correctly describes how the agentic loop terminates?

• AThe loop ends when the model returns stop_reason end_turn, and a response truncated by the output token limit is equivalent to that, because both indicate the model had nothing further it intended to emit.
• BThe loop ends once each tool exposed in the request has been called at least once, so an iteration ceiling only becomes relevant when the model calls the same tool repeatedly within one dispute.
• CThe loop repeats while the model returns stop_reason tool_use, running the requested calls and feeding the results back, and ends when it returns end_turn; the ceiling is an external circuit breaker that truncates work rather than a completion signal.check_circle Correct
• DThe loop ends when a tool result comes back with is_error unset, since a call that executed without error is the signal that the requested unit of work has been completed successfully.

Why A is wrong: Tempting because both stop the current response, but a truncated response means the model was cut off mid output, which is an incomplete turn rather than a signal that the task is finished.

Why B is wrong: Tempting because a full workflow does tend to touch every tool, but nothing in the loop tracks tool coverage, and a session may legitimately finish having called only get_customer.

Why C is correct: Correct: control alternates on stop_reason, so end_turn is the model's own statement that it is finished, while an iteration ceiling stops the harness irrespective of whether the work was done.

Why D is wrong: Tempting because is_error does report execution status, but a successful tool result is fed back to the model precisely so it can decide what to do next, which is the opposite of a termination signal.

The Meridian Platform team uses Claude Code for refactoring across a pnpm monorepo. They keep a root CLAUDE.md with house rules and a second CLAUDE.md inside packages/billing setting out currency rounding and money formatting conventions for that package. During a refactoring session an engineer works solely in packages/web, and the transcript shows the root conventions being applied while nothing from the billing memory file appears anywhere in context. What explains that behaviour?

• AThe root CLAUDE.md takes precedence over any nested memory file, so a nested file is consulted only in repositories where no root level memory file exists at all.
• BNested memory files are inert unless the root CLAUDE.md names them with an import line, and the root file in this repository declares no import for the billing package.
• CA CLAUDE.md held in a subdirectory is pulled into context on demand when Claude Code works with files in that subtree, so a session confined to packages/web does not trigger the billing file.check_circle Correct
• DClaude Code loads a single memory file per session, chosen from the working directory at launch, and discards every other CLAUDE.md it later encounters in the repository.

Why A is wrong: Precedence between scopes is a real concept, which makes this tempting, but precedence decides how conflicting guidance is weighed rather than whether a nested file is eligible to load. A root file does not suppress nested memory files.

Why B is wrong: Importing a file by path is a genuine way to pull it in, so this sounds mechanical and correct. It is wrong because a subdirectory CLAUDE.md is eligible on its own merits when work reaches that subtree, with no import required.

Why C is correct: Correct. Nested memory is scoped to its own part of the tree and is loaded when that part of the tree is actually touched, which is exactly why a session limited to another package sees no sign of it.

Why D is wrong: The single file model matches how many tools handle configuration, so it is a reasonable guess. It is wrong because several memory files at different scopes can be in play in one session rather than one winning outright.

An engineer on the Meridian Platform team adds a rule about running the type checker before any proposed refactor to the CLAUDE.md in her own home Claude directory, and confirms it takes effect in every repository she opens. Two colleagues then report that Claude Code proposes refactors on the same service without running the type checker, and a search of the checkout shows the rule is in none of the committed files. What does the placement of that rule guarantee?

• AIt applies to every project on her machine and is folded into the repository at her next commit, so colleagues pick the rule up as soon as they pull the branch she is working on.
• BIt applies to whichever repository was open when the file was last edited, because user scope memory is keyed to the working directory in force at the time of the change.
• CIt applies to every collaborator signed in to the same workspace, because user scope memory is synchronised through the account rather than through the repository checkout.
• DIt applies across every project on her own machine and travels with her user account, but it is not part of the repository, so a colleague's session does not load it.check_circle Correct

Why A is wrong: Sharing a convention by committing it is the right instinct, which makes this plausible. It is wrong because a user scope file lives outside the checkout and no commit sweeps it in; the rule has to be written into the project file deliberately.

Why B is wrong: Directory keyed behaviour genuinely exists for nested project memory, so borrowing it here feels consistent. It is wrong because the user scope file is not bound to a directory at all and is loaded whatever project is open.

Why C is wrong: Account synchronised settings are common in team tooling, so this reads as reasonable. It is wrong because user scope memory is a local file on one machine and carries no mechanism for distributing itself to other people.

Why D is correct: Correct. User scope memory is personal and machine local, so it reaches all of her own projects and none of anyone else's, which is precisely the split her colleagues are seeing.

To keep its project memory readable, the Meridian Platform team trims the root CLAUDE.md to a short set of house rules and points at two further documents using the import lines below. An engineer joining the team asks what Claude Code does with those lines when a session in the repository starts. What happens?

# Meridian Platform house rules
Prefer plan mode for any change spanning more than two packages.
Test layout and fixture rules: @docs/testing-conventions.md
Personal shell and tooling notes: @~/.claude/meridian-runtime.md

• ABoth documents are read and their contents become part of the loaded memory for the session, and an imported document may itself import further documents up to a bounded depth.check_circle Correct
• BEach import is deferred, so an imported document is fetched at the moment Claude Code is about to edit a file that the imported document happens to mention by name.
• COnly the import pointing inside the repository resolves, because a project memory file is confined to paths beneath the project root and cannot reach a document in the user's home directory.
• DThe two paths are recorded as references, so the import lines remain visible in context while the contents of both documents stay on disk until the engineer opens them by hand.

Why A is correct: Correct. Imports are expanded at load time, including recursively through a chain of files up to a defined limit, which is what makes splitting memory across documents workable.

Why B is wrong: Deferred loading is real for nested memory files placed in a subtree, so transplanting it onto imports feels consistent. It is wrong because an import is resolved when the importing file is loaded rather than triggered by a later edit.

Why C is wrong: A sandbox style restriction on project configuration sounds prudent and is common elsewhere. It is wrong because an import path may point at a home directory document, which is how a shared project file can pull in a personal notes file.

Why D is wrong: Treating a pointer as a pointer is an intuitive reading of the syntax. It is wrong because the point of an import is that the referenced text becomes part of the loaded memory rather than a path the model has to chase separately.

The Merge Gate team runs Claude Code inside the CI pipeline for their payments service, where a job reviews each pull request diff and posts comments back to the pull request. The review prompt instructs the model to flag any potential security concern. Across 300 pull requests, engineers dismiss 41 percent of the posted comments, and the same string-concatenation construct is flagged on one pull request and passed over on another with no code difference between them. Which statement best explains that inconsistency?

• AThe instruction names a category without stating a decision boundary, so each run resolves what counts as potential against that diff alone, and the precision of the output cannot settle at any particular level.check_circle Correct
• BThe job runs without a build-time budget, so a longer review reads more of the repository and reaches findings that a shorter review on another pull request never gets to.
• CThe job holds no record of earlier pull requests, so it cannot apply the precedent that a previous review set for the same construct on a different branch.
• DThe unified diff format hides the lines surrounding each hunk, so the model infers the missing context differently on each run and arrives at a different conclusion about the same construct.

Why A is correct: Correct. The word potential admits everything from a proven injection path to a theoretical one, so the model supplies the missing threshold itself on each invocation and the flag rate follows that inference rather than the team's intent.

Why B is wrong: Build time does change how much material a run covers, which makes this tempting, but the two pull requests here carry the same construct in the diff itself, so coverage is not what separates them.

Why C is wrong: It is true that each CI run starts without the history of previous runs, but a precedent is not what decides the call here; a written boundary in the prompt would settle the construct without any memory of past reviews.

Why D is wrong: Limited surrounding context is a real constraint on diff review and can affect hard cases, but it does not account for a 41 percent dismissal rate spread across findings the engineers judge to be non-issues on sight.

The Merge Gate team makes their CI review job return structured findings, each with a severity field restricted to the values blocker, major or minor by the schema fragment below, and the pipeline rejects any response that fails validation. Across one month every response validates cleanly and no run is rejected. A triage review then finds that 30 percent of the findings labelled blocker are formatting preferences that no engineer would hold a merge for. What does schema validation guarantee about those findings?

"severity": {
  "type": "string",
  "enum": ["blocker", "major", "minor"]
},
"file":    { "type": "string" },
"line":    { "type": "integer" },
"message": { "type": "string", "minLength": 20 }

• AIt guarantees that the labels were applied consistently within a response, because a single validated payload cannot mix two different readings of the criteria across its own entries.
• BIt guarantees only that the severity value is one of the three permitted labels, and says nothing about whether the finding satisfies the team's written definition of a blocker.check_circle Correct
• CIt guarantees that each finding came from the diff rather than the wider repository, since the file and line fields have to resolve to positions the pull request actually touched.
• DIt guarantees that a re-run against the same diff yields the same severity for the same defect, because a constrained field removes the variation that produces label drift.

Why A is wrong: Consistency within one response sounds like something structure would buy, but validation inspects each field independently; nothing compares one finding's severity reasoning against another's in the same payload.

Why B is correct: Correct. An enum is a constraint on the set of allowed strings. It admits the label blocker regardless of what the model applied it to, so semantic misclassification passes validation untouched.

Why C is wrong: The schema requires a string and an integer in those fields, not a position inside the changed lines; resolving a line to the diff would need a separate check the pipeline is not running.

Why D is wrong: Constraining the output alphabet narrows what can be emitted, not which of the permitted values the model chooses, so a re-run can move the same defect between bands and still validate.

A CI review job for the Merge Gate team asks the model to attach a self-reported confidence score between 0 and 1 to every pull request comment, and the pipeline suppresses any comment scoring below 0.8. The false positive rate moves from 38 percent to 31 percent. A sampled audit of the suppressed set finds two genuine null-dereference findings held back at 0.72, while several naming-convention opinions were posted at 0.95. Which statement explains that outcome?

• AThe threshold sits too high for the review prompt in use, and moving it to 0.6 would readmit the suppressed defects while keeping the naming opinions below the line.
• BConfidence scores hold for defect classes that appear often in review material and degrade for rarer classes, so null dereferences are scored low while familiar style issues are scored high.
• CA self-reported score expresses how certain the model is of its own assertion, which is a different quantity from whether the finding meets the team's criteria for a comment worth posting.check_circle Correct
• DThe score is produced after the comment text has been written, so it describes the model's certainty about the wording it just emitted rather than the defect the wording refers to.

Why A is wrong: Tuning a threshold is the obvious response, but the naming opinions scored 0.95 and the defects 0.72, so no threshold on this scale separates them; lowering the line admits more of both.

Why B is wrong: Frequency effects on model behaviour are real, which makes this plausible, but null dereferences are among the most common defects in review material, so the premise does not fit the observed split.

Why C is correct: Correct. A style opinion can be asserted with complete certainty and still be unwanted, while a genuine defect can be flagged tentatively, so ranking by self-reported certainty does not rank by usefulness.

Why D is wrong: The ordering is right and the conclusion is close, but the flaw is not that the score attaches to wording; it is that a self-report of certainty is unrelated to whether the finding meets the team's bar for posting.

The Resolution Desk team adds a second MCP tool, find_account, alongside the existing get_customer on their Customer Support Resolution Agent. get_customer is described as retrieving a customer record by identifier, and find_account is described as retrieving an account record by identifier. Both take a single string argument. Across 800 sessions the agent calls find_account in roughly half of the identity checks the team intended to route to get_customer, with no pattern the team can predict from the transcripts. Which statement best explains that split?

• AThe two tools return records of different shapes, so the agent deliberately alternates between them across sessions in order to compare the two results before it answers the customer's opening question.
• BThe MCP server registers tools in the order they are listed in the project .mcp.json file, and the model is required to select the earlier registration whenever two tools accept an argument of the same type.
• CIdentical input schemas make validation reject one of the two calls, after which the harness automatically retries the request against the sibling tool, which is what produces an even split of calls across the sessions.
• DTool selection is driven by the tool name and the description text, so two descriptions stating the same capability in different words give the model no discriminating signal, and the choice then varies with the wording of each customer's message.check_circle Correct

Why A is wrong: Tempting because the tools genuinely do return different record shapes, but the agent has no comparison behaviour of that kind; it selects one tool per intent, and nothing in the loop asks it to sample alternatives.

Why B is wrong: Registration order is real, but it carries no selection precedence of this sort, and a rule like this would produce a consistent bias rather than the unpredictable half-and-half split observed.

Why C is wrong: Plausible if you assume schemas are compared across tools, but validation checks a call against its own tool's schema only, and there is no automatic retry that reroutes a call to a different tool.

Why D is correct: Correct. The description is the routing surface, and two overlapping descriptions leave the selection to incidental phrasing, which is exactly the unpredictable split the team measured.

The Resolution Desk team originally exposed one MCP tool named account_action, taking an operation argument that accepted the values refund, cancel, credit and hold, with a single description paragraph covering all four operations. They replaced it with four separately named tools, each carrying its own description, and left the underlying server logic untouched. Calls that performed the wrong operation fell from 9 percent of billing contacts to under 1 percent. Which statement best explains that improvement?

• AEach operation now carries its own name and its own description that the model matches against the request independently, instead of four branches competing for the discriminating detail in one shared description paragraph.check_circle Correct
• BSchema validation can now reject an operation the customer did not ask for, because each tool declares a narrower set of accepted values than the shared operation argument did before the split was made.
• CThe narrower input schema on each tool means the model generates fewer argument tokens per call, and shorter generated arguments are less likely to contain a mistaken value than the longer arguments the shared tool required.
• DRemoving the enumerated value list means the operation is expressed as free text, and the model handles free text more reliably than a constrained list of permitted values when it is deciding what the customer wants.

Why A is correct: Correct. Splitting gives each operation a full routing surface of its own, so the detail that separates a credit from a refund no longer has to share a few sentences with three other operations.

Why B is wrong: Validation does check a narrower schema now, but it has no knowledge of what the customer asked for, so it cannot reject a semantically wrong but well formed call; the improvement happened before validation runs.

Why C is wrong: Argument length is a real cost consideration, but the errors were in which operation was chosen rather than in producing the argument text, so this addresses the wrong layer of the problem.

Why D is wrong: This reverses the usual relationship, since constrained value lists help rather than hinder; it also misdescribes the change, which replaced one tool with four rather than loosening a constraint.

On the Customer Support Resolution Agent, lookup_order finds no matching orders when a customer quotes an order number belonging to a different retailer, which happens in about 3 percent of contacts. To make the condition visible in their logs, the Resolution Desk team sets is_error to true on the tool result returned for that case. Over the next fortnight escalations rise from 4 percent to 15 percent of contacts, and transcripts show the agent telling customers that the order system is unavailable. Which statement best explains the rise?

• AA result carrying is_error true ends the agentic loop with a stop_reason of end_turn, so the agent has no opportunity to continue working the contact and the harness routes the session to a human queue instead.
• BA tool result flagged as an error is presented to the model as a failed call, so a valid finding of no matching order now reads as a broken dependency, and the agent responds with the recovery behaviour it would use during an outage.check_circle Correct
• CThe flag causes the MCP server to withdraw the failing tool from the agent's available set for the remainder of the session, which leaves escalation as the only route still open once an order lookup has failed once.
• DResults marked as errors are excluded from the conversation the model can see, so the agent loses any record of having searched, repeats the same lookup, and eventually runs the contact out of turns and into the escalation path.

Why A is wrong: Tempting because stop_reason is the real termination signal, but an error result is returned into the conversation like any other tool result and the loop continues; the escalations came from the model's own choice, not from a forced stop.

Why B is correct: Correct. The flag changes how the result is framed to the model, converting a legitimate empty answer into an apparent infrastructure failure, which is what produces the outage language and the handover.

Why C is wrong: No such withdrawal mechanism exists; a tool stays available after an error result, and this would predict a single failed lookup per session rather than the observed pattern.

Why D is wrong: Error results remain in the conversation and are visible to the model on the next turn; the transcripts also show outage language rather than the repeated identical lookups this explanation predicts.

The Resolution Desk team runs their Customer Support Resolution Agent with automatic context compaction: once a session passes 30 turns, the earlier turns are replaced by a model written summary and the raw turns are discarded. In one billing dispute the customer stated a disputed amount of 149.00 in turn 6, the summary written at turn 31 recorded only that a billing amount was in dispute, and at turn 44 the agent called process_refund for the full order value of 320.00. Which statement best explains this outcome?

• AThe compaction step ran because the request had already exceeded the context window, so the turns holding the disputed amount were truncated before the summary could be written from them.
• BThe process_refund input schema accepted 320.00 because that value sits under its maximum of 500, and that acceptance is what allowed a figure the customer never asked for to be paid out.
• CThe session ran against a smaller context window than a 44 turn dispute requires, and moving the same workload to a model configured with a larger window would have retained the turn that held the figure.
• DSummarisation is lossy, so a detail omitted from the summary is simply absent from the context afterwards, and once the raw turns were discarded the session held no remaining source from which the agent could recover the 149.00 figure.check_circle Correct

Why A is wrong: Tempting because both overflow and compaction remove earlier turns, and an architect who has seen truncation errors will reach for that first. It is wrong because compaction runs to keep a session inside the window rather than as a consequence of breaching it, and turn 6 was available to the summariser, which simply did not carry the figure forward.

Why B is wrong: Tempting because the schema genuinely did accept the call and a tighter bound feels like the missing control. It is wrong because schema validation checks the shape and range of an argument rather than whether the value is the correct one, so it explains nothing about where the 320.00 came from.

Why C is wrong: Tempting because a larger window does postpone the point at which compaction fires. It is wrong here because the loss happened inside the summarisation step rather than at the window boundary, so a bigger window changes when the same lossy compression occurs rather than whether it drops the amount.

Why D is correct: Correct. Compaction replaces turns with a compressed rendering of them, and anything the summariser drops is gone from the session state. The agent then reasoned from the only figure still present, the order value, because the disputed amount had no surviving representation anywhere in its input.

The Resolution Desk team keeps a persistent case facts block holding the verified customer identifier, the order identifier and the disputed amount, and injects it once, at the point where verification completed, which is roughly a third of the way through a typical 60 turn dispute. Reviewers find the Customer Support Resolution Agent restates those facts accurately in short sessions but misquotes the order identifier in about one dispute in five once sessions run long. Which mechanism best explains that pattern?

• ARecall of material sitting in the middle of a long input degrades relative to material at the start or the end, so the block loses salience as further turns accumulate on both sides of it.check_circle Correct
• BThe block is dropped from the request as soon as the conversation exceeds the context window, so on long disputes the agent is answering from the surrounding turns rather than from the facts it was given.
• CTool results returned after the block overwrite it in the conversation state, so only the most recent tool payload stays addressable to the model and the earlier identifiers become unreadable.
• DInjecting the facts as a user message rather than as a system instruction strips their authority, so the agent treats each identifier as an unverified customer claim and substitutes a value it prefers.

Why A is correct: Correct. The failure rate tracks conversation length rather than any change in the block itself, which is the signature of position dependent attention. Facts buried between a long prefix and a long suffix are attended to less reliably than the same facts placed at either boundary.

Why B is wrong: Tempting because window pressure is a real cause of missing content in long sessions. It is wrong because a dropped block would produce a refusal or an explicit request for the identifier rather than a confident misquotation, and the failure appears well before the window fills.

Why C is wrong: Tempting because tool results do dominate the recent context by volume. It is wrong because messages accumulate rather than overwrite one another, so the block remains in the request; volume dilutes attention rather than deleting content.

Why D is wrong: Tempting because message role genuinely affects how strongly guidance is weighted. It is wrong because a loss of authority would show as hedging or re-verification, and it would appear in short sessions too, whereas this failure is conditional on length.

The lookup_order tool used by the Customer Support Resolution Agent returns a full order record whose delivery event log runs to about 400 lines. To bound context growth the Resolution Desk team wraps the tool so that only the first 30 lines of the payload are returned into the conversation. Token use per dispute falls by a third, but the agent starts telling customers that no delivery attempt was recorded, because the attempt lines sit near the end of the log. Which statement correctly describes what the trimming guarantees?

• AIt guarantees the agent will issue a second lookup_order call whenever the retained slice is insufficient, because a truncated tool result is surfaced to the model as an incomplete payload it is expected to complete.
• BIt guarantees a bound on the tokens the payload adds and nothing more, saying nothing about whether the retained slice holds the fields the task needs, which is why selecting fields by relevance outperforms positional truncation.check_circle Correct
• CIt guarantees the discarded lines stay retrievable for the rest of the session, because the harness holds the untrimmed payload alongside the trimmed one and can supply it when the agent asks a follow up question.
• DIt guarantees the retained lines are the ones relevant to the customer's request, because the opening lines of an order record carry its identifying fields and the remainder is chronological detail of lower value.

Why A is wrong: Tempting because a well designed wrapper could annotate the truncation and prompt a follow up. It is wrong because a silent slice arrives looking like the whole result, so the agent has no signal that anything is missing and treats the absence of attempt lines as evidence of no attempt.

Why B is correct: Correct. A fixed line cap is a size control, not a relevance control. It reliably caps growth while leaving the retained content determined by the payload's layout rather than by the question, so a field aware projection preserves the same saving without the blind spot.

Why C is wrong: Tempting because caching the full payload outside the conversation is a sensible design. It is wrong as a description of what trimming alone does: only what is placed into the conversation is visible to the model, and a wrapper that discards the remainder leaves nothing to serve.

Why D is wrong: Tempting because leading fields often are the identifying ones, which is why first N truncation looks safe. It is wrong because relevance depends on the question asked, and a delivery query needs exactly the tail that positional truncation removes.