8 of the 15 questions in this set, with the correct answer marked and every option explained.
1. What does the temperature parameter control in a text generation request?
✓How much randomness is applied when sampling the next token — lower values concentrate probability on the most likely tokens, higher values flatten the distribution.
Temperature rescales the logits before sampling. Near zero the model becomes close to deterministic and picks the highest-probability continuation; higher values give lower-probability tokens a real chance, producing more varied and less predictable output.
✗How many tokens the model is permitted to generate.
That is max_tokens, a separate parameter governing length rather than selection.
✗How fast the model generates tokens.
Generation speed depends on the model and infrastructure. Temperature does not affect throughput.
✗How much of the conversation history the model attends to.
The model attends to everything in the request. Temperature affects sampling, not attention.
2. For a task where the same input must reliably produce the same classification label, which configuration is most appropriate?
✓A very low temperature together with a constrained output format such as a fixed enumeration of allowed labels.
Low temperature removes most sampling variance and constraining the output space removes format variance. Together they give the consistency a classification pipeline needs, whereas either alone still leaves room for drift.
✗A high temperature so the model considers more possibilities before deciding.
High temperature increases variation in the output token itself. For classification that means the same input can yield different labels across calls.
✗No system prompt, so the model is not biased toward any label.
Omitting instructions does not produce neutrality — it produces unspecified behaviour, including inventing labels outside your taxonomy.
✗A very high max_tokens so the model can explain each classification at length.
Length does not improve label consistency and adds cost. If reasoning is wanted, it should be requested as a separate structured field.
3. An application must keep per-request cost predictable as conversations grow. What is the most important thing to manage?
✓The number of input tokens sent per request, since a growing conversation history is re-sent and re-billed on every call.
Chat APIs are stateless, so history is resent each time and input tokens grow with the conversation. Left unmanaged, cost per request climbs steadily even though each user message stays short.
✗The number of distinct API keys in use.
Keys are for authentication and attribution. They have no effect on per-request cost.
✗The frequency of model version updates.
Model choice affects unit price, but the runaway cost in a long conversation comes from token growth.
✗The size of the response JSON envelope.
Protocol overhead is negligible next to token consumption.
4. In function calling, what does the model actually produce?
✓A structured request naming the function and supplying arguments matching its schema — the application executes it and returns the result.
The model never executes anything. It emits an intent to call, and the application decides whether and how to honour it, which is what keeps every side effect under the application's control.
✗Executable code that the API runs in a sandbox automatically.
That describes a code interpreter tool, a different capability. Function calling emits a structured call for your code to execute.
✗A natural language instruction for a human to carry out.
The output is machine-readable and schema-conformant precisely so it can be dispatched programmatically.
✗A direct HTTP request sent from the model provider to your endpoint.
The provider does not call your services. The response comes back to your application, which makes any onward calls itself.
5. A developer notices the model calls a search function even for questions it could answer directly, adding latency and cost. What is the most effective fix?
✓Sharpen the function description to state when it should be used and when it should not, so the model has a clearer decision boundary.
Tool selection is driven by the description. Stating the negative case explicitly — when not to call it — is often more effective than describing the positive case alone, and requires no code change.
✗Remove the function entirely.
This eliminates the over-calling by eliminating the capability, which fails the cases that genuinely need search.
✗Raise the temperature so the model varies its choices.
This makes tool selection less predictable, not better targeted.
✗Rename the function to something shorter.
Length of the name is not what drives selection. The description carries the semantics.
6. An agent has a tool that issues refunds. What is the appropriate control?
✓Enforce limits in the application — amount ceilings, eligibility checks and human approval above a threshold — rather than relying on the model to refuse inappropriate refunds.
Financial actions need deterministic controls at the execution boundary. The model can propose a refund; the application decides whether the request satisfies the business rules, and that decision must not depend on model judgement.
✗Instruct the model in the system prompt to only issue reasonable refunds.
'Reasonable' is undefined and unenforceable, and prompt instructions are guidance rather than controls. This is a policy statement, not a safeguard.
✗Log refunds and review them monthly.
Detection after the money has moved is not prevention. Useful as a supplementary control, insufficient as the primary one.
✗Restrict the tool to a lower-capability model to reduce risk.
A less capable model is more likely to misjudge, not less. Capability is not the control surface here — the execution boundary is.
7. What is the practical benefit of an agents framework over hand-rolling the tool-calling loop?
✓It provides tested implementations of the repetitive parts — loop control, tool dispatch, handoffs, tracing and error handling — so effort goes into tools and prompts instead.
Every team that hand-rolls this eventually writes the same loop, the same retry logic and the same tracing, usually with subtle bugs. A framework standardizes that plumbing and typically brings observability that is tedious to build from scratch.
✗It makes the underlying model more accurate.
Framework choice does not change model capability. It changes the ergonomics and reliability of the code around the model.
✗It removes the need for prompt engineering.
Instructions still determine behaviour. A framework organizes where prompts live; it does not write them.
✗It guarantees the agent cannot take unintended actions.
Frameworks provide mechanisms for guardrails, but the guarantees come from how you configure permissions and approvals — not from adopting the library.
8. Which approach most reliably guarantees that a response conforms to a required JSON schema?
✓Use the API's structured output or schema-constrained mode, so conformance is enforced during generation.
Constraining decoding to the schema makes non-conforming output impossible rather than merely unlikely. Prompt-based requests for JSON work most of the time, and the residual failures are what break production parsers.
✗Ask for JSON in the prompt and retry when parsing fails.
Workable as a fallback but wasteful and unreliable — retries add latency and cost, and a persistent formatting confusion can loop.
✗Request JSON and strip any surrounding text with string slicing.
Brittle. Nested braces, code fences and embedded JSON in prose all defeat naive slicing.
✗Lower the temperature to zero and assume the format will be consistent.
Determinism makes output repeatable, not correct. A consistently malformed response is still malformed.
7 more questions in the app
Practise the full 15-question set with a timer, scoring and progress tracking.