CCDV-F - Model Selection and Optimization (16.8% of the exam) - Section 5.1
Apply a basic understanding of large language models and their model options.
Published skill weight 5.2 percent. Covers tokens, context windows, sampling, non-determinism and next-token generation; model options including fast mode, extended thinking, adaptive thinking and effort levels; and the fundamental prompting techniques of zero-shot, single-shot and multi-shot.
tokens and context windowssampling and non-determinismnext-token generationextended and adaptive thinkingeffort levelszero-shot, single-shot, multi-shot
Practice question for this objective
lock_openFree sampleModel Selection and Optimizationeasy
A finance service handles two request classes through one code path: simple balance lookups, which make up most of the traffic, and multi-step contract reconciliations. Extended thinking is switched on for every request. A review of live traffic shows the lookups meet the agreed quality bar with extended thinking switched off, while the reconciliations fall below it without it. Spend per request is above the team's stated ceiling. Which change fits the stated constraints?
AEnable extended thinking only for the reconciliation class, which the measurement shows needs it, and run the balance lookups without it.check_circle Correct
BSwitch extended thinking off for the whole service and accept the lower reconciliation quality, since the stated cost ceiling applies to every request the service handles.
CKeep extended thinking on everywhere and reduce the value of max_tokens so that each reply is shorter, bringing the measured spend per request under the stated ceiling.
DKeep extended thinking on everywhere and negotiate a higher cost ceiling with finance, on the basis that reasoning depth is a fixed property of the service rather than a per-request choice.
Extended thinking is a per-request quality lever with a cost, so apply it to the request class measured to need it. Extended thinking raises answer quality on multi-step reasoning by spending more tokens before the reply, so it is a cost decision taken per request rather than a global setting. Traffic here splits cleanly into a class that clears the quality bar without it and a class that does not, so routing the setting by class holds both the quality bar and the cost ceiling.
Why A is correct: Correct: extended thinking buys reasoning depth at an extra cost per request, so it belongs on the class measured to need it and off the class measured to clear the bar without it.
Why B is wrong: Tempting because it certainly meets the ceiling, but it knowingly drops the reconciliations below an agreed quality bar when the measurement shows only that class needs the extra reasoning.
Why C is wrong: Tempting because it looks like a direct cost lever, but it caps the reply rather than the reasoning effort, so the lookups keep paying for thinking they do not need and long answers are cut short.
Why D is wrong: Tempting because it protects quality, but the stated ceiling is the constraint to design against, and the measurement already shows the depth is not needed on the majority class.
Answers that look right on this material and are not. Each one is a distractor from a different question in the CCDV-F bank for this domain.
Accept it, because extended thinking gives the model room to check its own reply against the field list before answering, which is what the measured failures show is missing.
errorWhy it is wrong: Tempting because self-checking does improve on hard reasoning tasks, but the failure here is an unenforced output shape rather than a reasoning shortfall, so the extra spend buys no guarantee.
The architect is right, and the team should instead send its documents to a third-party service that resells classification, since only that route avoids a language rewrite.
errorWhy it is wrong: It appears to respect the four-week window, but it accepts a false premise and adds a third party to the data path for a call the team can make itself.
Keep sending every document but switch the job to the Message Batches API, so the whole set is processed at the lower rate that latency-tolerant work attracts.
errorWhy it is wrong: Tempting because the job genuinely is latency tolerant and batching is the right transport for it, but it still pays to have the model decide something a checksum decides for nothing, so most of the waste remains.