Free AI Foundations practice test

Correct: The OpenAI Chat Completions API structures conversations using three roles — 'system' (sets the model's behavior/persona), 'user' (represents the human's input), and 'assistant' (represents the model's prior responses, used to maintain conversation history). Option A uses terms from older prompt-engineering conventions but does not map to actual API role names. Option D ('instruction, input, output') is terminology associated with fine-tuning data formats (e.g., Alpaca), not the Chat Completions API message roles. Option C ('query, memory, completion') does not correspond to any standard API role naming and reflects a common misconception about how conversational state is managed.

Gemini was positioned as the successor to Google's PaLM and PaLM 2 model families, which powered earlier versions of Bard. BERT is an encoder-only model primarily used for classification/embeddings, not a generative chat model successor. T5 is an encoder-decoder model used for text-to-text tasks — not Gemini's direct predecessor in the product line. LaMDA was the original conversational model behind early Bard, but it was PaLM/PaLM 2 that served as the primary predecessor to Gemini; LaMDA was not 'based solely on BERT'.

Correct answers are A and C. A is correct: a core advantage of open-weight models is the ability to deploy them on-premises or in a private cloud, keeping all data within organizational boundaries — a significant compliance benefit. C is correct: hosted APIs do transfer some security/infrastructure burden to the vendor, but this introduces a dependency on the vendor's data handling, retention policies, and BAAs, which must be carefully evaluated for compliance. Option B is wrong because GDPR compliance depends on data handling practices, contracts, and organizational policies — not simply on whether a third party is involved; on-premises deployments still require compliance work. Option D is wrong because open-weight model licenses vary significantly: Llama 3 has usage restrictions for large commercial deployments, Mistral uses Apache 2.0, and Falcon has its own license — blanket statements about permissive commercial use are inaccurate. Option E is wrong because enterprise API agreements typically include data processing agreements and options to opt out of training data use; the claim that hosted APIs are categorically unsuitable for regulated use is an overstatement.

The OpenAI Chat Completions API uses three defined roles: 'system' (sets the assistant's behavior/persona), 'user' (represents the human's input), and 'assistant' (represents the model's previous responses). These three together form a multi-turn conversation history. 'prompt, context, and response' are informal terms, not API role names. 'instruction, human, and bot' are role names used by some other frameworks (e.g., Alpaca-style fine-tuning) but not the OpenAI API. 'prefix, query, and reply' are not defined roles in any major chat API.

Zero-shot prompting is correct because the task is simple and well-defined—the model can generate a one-sentence product description from a direct instruction alone without needing examples. Few-shot prompting (B) adds unnecessary overhead for a straightforward task; it is most valuable when the output format is non-obvious or the task is complex. Chain-of-thought (C) is designed for multi-step reasoning problems and would over-complicate a simple generation task. Self-consistency (D) is an ensemble technique meant to improve accuracy on complex reasoning; it is wasteful and unnecessary for simple description generation.

Zero-shot prompting means giving the model a direct instruction and asking it to perform a task with no examples provided. The developer is relying entirely on the model's pre-trained knowledge. Few-shot prompting would include labeled example emails. Chain-of-thought asks the model to reason step by step. Self-consistency involves generating multiple responses and taking a majority vote.

Option C is correct because adding an explicit format instruction directly tells the model the expected output structure, resolving inconsistency without requiring examples. Option A is wrong—raising temperature increases randomness, which would make output format even less consistent. Option D (role prompting) can improve quality but does not by itself enforce a specific output format; it is a secondary concern here. Option B is wrong because top-p=1.0 means no nucleus truncation and would, if anything, increase randomness, not enforce format consistency.

Input validation/sanitization (A) removes or neutralizes malicious instructions before they reach the model. Clear delimiters (C) help the model structurally distinguish trusted system instructions from untrusted user content. A pre-processing classification step (F) can flag or reject adversarial prompts before they are processed. Increasing temperature (B) has no security benefit and would make outputs less predictable. Instructing the model to ignore user instructions (D) is a weak mitigation—models can still be manipulated, and this alone is insufficient. Switching output format (E) does not address the injection vector at all.

Multi-query retrieval generates multiple reformulations of the original query and retrieves candidates for each, improving recall by capturing different aspects of the question — this matches the 'three phrasings' step. Cross-encoder reranking then re-scores the merged candidate set using a cross-encoder model that jointly considers the query and each passage, improving precision before generation. (F) HyDE generates a hypothetical answer and embeds it; it is not described here. (D) Parent-child chunking controls what chunk size is indexed vs. returned; it is not described here. (E) Fixed-size chunking is an ingestion-time strategy, not a query-time technique. (B) BM25 is a keyword retrieval method; the pipeline here uses vector search only.

Cosine similarity measures the cosine of the angle between two vectors, making it effective for high-dimensional semantic embeddings because it is invariant to vector magnitude—only direction matters. (C) Euclidean distance measures raw geometric distance and is sensitive to vector magnitude, making it less robust for high-dimensional embedding spaces. (A) Jaccard similarity operates on sets (intersection over union) and is not directly applicable to dense continuous vectors. (D) Manhattan distance sums absolute differences and, like Euclidean distance, is magnitude-sensitive and less commonly used for semantic similarity in dense embeddings.

C is correct: Recursive character chunking uses a priority list of separators (e.g., double newlines, single newlines, sentences) and only falls back to character splitting when necessary. For Q&A documents that are naturally separated by newlines, this keeps each Q&A pair intact. A is wrong: Simply increasing the chunk size may fit more pairs into one chunk, but it also mixes unrelated Q&A pairs together, hurting precision. B is wrong: Sentence-level chunking respects sentence boundaries but still may split a multi-sentence question from its answer if they are in separate sentences with no special handling. C better matches the document's natural structure (newline-delimited pairs). D is wrong: HyDE is a query-time retrieval technique, not a chunking strategy.

Correct: Multi-query retrieval (popularized in LangChain's MultiQueryRetriever) generates several reformulations of the original query using an LLM, performs independent retrieval for each, and merges the result sets. This improves recall for ambiguous queries because different phrasings may activate different regions of the embedding space. | Wrong A: HyDE generates a hypothetical answer document (not alternative questions) and embeds that document to use as the query vector; it addresses a different problem (improving the query vector representation). | Wrong C: Cross-encoder reranking improves precision of an already-retrieved candidate set; it does not expand the candidate set through multiple queries. | Wrong D: Parent-child chunking is an indexing strategy that stores small child chunks for retrieval but returns larger parent chunks for context; it is unrelated to query reformulation.

message_stop is the final event emitted by the Anthropic streaming API and definitively signals that the entire message, including all content blocks, has been fully generated and the stream is closed.

Why the distractors are wrong:

• (B) content_block_stop signals the end of a single content block (e.g., a text segment), not the end of the full message. Multiple content blocks can exist in one message.
• (A) message_delta with stop_reason: "end_turn" carries metadata about why generation stopped, but it precedes message_stop; it is not itself the terminal signal.
• (D) stream_end is not a real Anthropic SSE event type; this is a distractor.

Anthropic's API authenticates with a custom header x-api-key: <YOUR_API_KEY>, unlike OpenAI, which uses the standard Authorization: Bearer header. Developers used to OpenAI often put the key in Authorization: Bearer, and this produces a 401 Unauthorized error. The missing Content-Type explanation is incorrect: Content-Type: application/json is required for POST requests, but leaving it out typically causes a 400 error about the request body, not a 401 authentication error. The Base64-encoding explanation is incorrect because API keys are passed as plaintext strings in headers; Base64 encoding is used in HTTP Basic Auth, not API key auth. The OAuth 2.0 token exchange explanation is incorrect because Anthropic uses simple API key authentication, not OAuth 2.0 token flows.

The correct three-step sequence is: (A) append the assistant message that contains the tool_calls so the model has context for what it asked; (D) execute the tool and append the role: 'tool' message with the result and matching tool_call_id; and (E) send the full updated messages array in a new API call so the model can generate the final answer. Option B is wrong — discarding history in a new conversation loses all context. Option C describes the actual function execution, which is necessary, but it is a prerequisite to step D and not itself a step in the API conversation structure. Option F is wrong — setting tool_choice: 'none' is an optional safeguard, not a required step, and the model will stop calling tools naturally once it has the result it needs.

Options A, D, and E are correct. OpenAI caches eligible prompts automatically (no markup needed) once they exceed the minimum threshold, whereas Anthropic requires explicit cache_control: {"type": "ephemeral"} markup on the blocks to cache. Anthropic's cache TTL is 5 minutes from the last use and resets with each cache hit. Option C is wrong — both providers charge reduced rates for cache hits (not full input prices); cached tokens are significantly cheaper than uncached input tokens. Option F is wrong — OpenAI's minimum cacheable prompt threshold is 1,024 tokens for GPT-4o and several other models, which is actually correct per documentation; however, for this question context the distractor tests awareness that this threshold exists but is not universal across all models. Option B is wrong — OpenAI's prompt cache is scoped to the same API key/organization and is ephemeral (typically a short TTL), not permanently stored.

When untrusted user input is concatenated directly into a prompt sent to an LLM, an attacker can inject instructions that override the system's intended behavior. This is prompt injection. The primary mitigations are validating and sanitizing input, plus filtering output before acting on the model's responses. SQL injection with parameterized queries is about database queries, not how LLM prompts are built. CSRF with anti-CSRF tokens is about forged cross-origin HTTP requests, not manipulating an AI prompt. Model poisoning with retraining targets training data, but this attack happens at inference time, not training time.

Opening the interface/type definition files is correct: they show the model the contracts it must fulfill, which is among the most useful context it can get. Writing a brief inline comment above the function is correct: a descriptive comment right before a function is one of the most reliable ways to steer AI completions toward correct behavior, because it acts as a local specification. Keeping related utility/helper files open in adjacent tabs is correct: it lets Copilot and similar tools reuse existing code instead of inventing new implementations, which keeps the code consistent. Opening every file in the monorepo backfires: it fills the context window with mostly irrelevant content and makes suggestions worse, and most tools use a sliding or ranked context window anyway. Including files from an unrelated project adds noise and conflicting style signals that confuse the model. Deleting code comments removes context that helps the model understand intent, and the token savings are small compared with the loss in accuracy.

Requiring pull requests with human reviewer approval, enforced through branch protection rules, is correct: this is GitHub's standard way to block direct commits to main, so a human reviews every change no matter how it was written. Running AI-assisted review on feature branches before requesting human review is also correct: automated pre-screening (e.g., Copilot Chat or another tool flagging issues) adds a layer of defense and improves review quality. Having Copilot auto-open a pull request on each accepted completion is wrong because Copilot is an in-editor completion tool, not a git workflow automation, and cannot open pull requests when a suggestion is accepted. Treating Copilot Chat's '/review' output as self-certification is wrong because that output is only advisory; it cannot certify code or replace a human reviewer under branch protection. Disabling Copilot on main through a repository-level environment variable is wrong because GitHub offers no such mechanism; Copilot is controlled through organization and user settings, not per branch.

This scenario captures a key AI coding tool risk: models frequently generate SQL with string interpolation rather than parameterized queries, which is a SQL injection vulnerability. Even though user_id comes from a JWT, the security reviewer is right to flag it — JWT libraries can have parsing bugs, tokens can be tampered with if not verified correctly, and defense-in-depth requires treating all inputs to SQL queries as untrusted. The correct fix is to use a parameterized query (e.g., db.execute('SELECT * FROM users WHERE id = ?', (user_id,))). The f-string claim is false; f-strings are supported in Python 3.6+ and are universally available in modern production environments. The missing return type annotation is a real best practice but a minor style concern — it is not a security risk and is not the 'primary' concern. The SELECT * denial-of-service answer incorrectly focuses on performance; while SELECT * can be inefficient, the primary and critical concern here is SQL injection, not column retrieval width.