Design applications Study Guide — Generative AI Engineer Associate

Design Applications

This domain tests your ability to translate business requirements into concrete GenAI application designs: choosing the right prompt strategy, selecting the appropriate model task, assembling multi-stage reasoning chains, deciding when prompting alone is sufficient versus when RAG or fine-tuning is required, and specifying quality guardrails before writing a single line of code. It accounts for 14% of the exam, making it one of the mid-weight domains. Expect scenario-based questions that describe a business need and ask you to identify the best design decision from a set of plausible alternatives.

Prompt Design: Zero-Shot, Few-Shot, Chain-of-Thought

Core Concepts

Prompting is the act of constructing the text input sent to a language model to elicit a desired output. The prompt design you choose directly affects output quality, reliability, and cost. The three canonical strategies tested on the exam are:

Zero-shot prompting: You describe the task in natural language with no examples. The model relies entirely on its pre-trained knowledge. Best for well-understood, simple tasks where the output format is familiar to the model.

Few-shot prompting: You provide a small number of input-output demonstration pairs (typically 2–8) inside the prompt before the actual query. The model learns the expected format, tone, and reasoning style from the demonstrations. Best when the task has an unusual format, a specific output schema, or domain-specific vocabulary the model may not default to correctly.

Chain-of-thought (CoT) prompting: You instruct the model to reason step-by-step before producing a final answer, either by adding a phrase like "Think step by step" (zero-shot CoT) or by including demonstration examples that show intermediate reasoning steps (few-shot CoT). Best for multi-step arithmetic, logic puzzles, and complex reasoning tasks where intermediate steps reduce error.

Comparison Table

Common Traps

• Assuming more examples always help: Beyond ~8 examples, additional examples inflate token cost with diminishing accuracy returns. The exam may offer "16-shot" as a distractor implying it is always better.
• Confusing CoT with few-shot: CoT is about showing reasoning steps, not just input-output pairs. A few-shot prompt without reasoning steps is NOT chain-of-thought.
• Using CoT for simple tasks: CoT adds latency and cost; for a simple classification task it is overkill and the exam may present it as the wrong answer.
• Ignoring prompt injection risk: Few-shot prompts that include user-supplied text in the examples can expose the application to prompt injection. The exam may include guardrail questions tied to this risk.

Worked Scenario

Requirement: A financial firm needs a model to extract structured JSON from unstructured analyst notes. The JSON schema is proprietary and unfamiliar to general-purpose models.

Reasoning: The output schema is non-standard, so zero-shot will likely produce inconsistent JSON keys. CoT is unnecessary because this is a formatting/extraction task, not a reasoning task. Few-shot prompting with 3–5 examples showing note → JSON pairs is the correct answer.

Selecting Model Tasks from Requirements

Core Concepts

Large language models are general-purpose, but you must map each business requirement to a specific model task. The exam tests whether you can read a business description and identify the correct task type.

Common Traps

• Summarization vs. Extraction: Summarization produces a prose digest. Extraction produces structured data (e.g., a list of names or a JSON object). If the requirement says "pull all contract dates into a table," that is extraction, not summarization.
• Chat vs. QA: Chat implies statefulness across turns. QA can be stateless (one question, one answer). If the requirement says "users will ask follow-up questions," the task is chat, not plain QA.
• Classification vs. Extraction: Classification assigns one (or a fixed set of) labels. Extraction pulls variable-length data. If the requirement is "determine if this email is a complaint," that is classification.

Worked Scenario

Requirement: A legal team wants to automatically read uploaded NDAs and produce a structured report listing every party name, effective date, and termination clause.

Reasoning: The output is structured (specific fields), not a prose summary. The task is information extraction, likely requiring a schema-aware prompt (few-shot) producing JSON or a table. Summarization would discard the specific structured data needed.