Apply Prompt Engineering Techniques: Zero-Shot, Few-Shot & Chain-of-Thought

CCAR-P Exam Guide — Domain 2: Claude Models, Prompting & Context Engineering

Exam: Claude Certified Architect – Professional (CCAR-P) Domain 2: Claude Models, Prompting & Context Engineering — 13% Target objective: Apply prompt engineering techniques — zero-shot, few-shot, chain-of-thought Closely related objective: Design system prompts, templates, and guardrails

---

1 What You Need to Know for the Exam

For CCAR-P, think about prompt engineering through this decision:

What information is missing from the basic instruction that Claude needs in order to perform the task reliably?

Usually the answer falls into one of three categories:

Situation	Technique
Task is clear and Claude can infer the behavior directly	Zero-shot
Desired behavior, format, classification boundary, tone, or edge handling is difficult to describe but easy to demonstrate	Few-shot
Task involves genuinely difficult multi-step reasoning where intermediate reasoning improves the result	Chain-of-thought / reasoning

This distinction is strongly reflected in both supplied practice exams. In particular, the practice questions repeatedly distinguish:

• hard multi-step reasoning → chain-of-thought
• unusual output format → few-shot
• ambiguous classifications best demonstrated by examples → few-shot
• persistent persona and behavioral instructions → system prompt

That is probably the most important decision framework to memorize.

---

2 The Big Picture: Prompt Architecture

Before studying zero-shot, few-shot, and chain-of-thought independently, understand where they fit.

A well-designed Claude request can conceptually look like:

SYSTEM PROMPT
│
├── Role / persona
├── Persistent behavioral instructions
├── Standing constraints
├── Output conventions
└── Escalation / uncertainty behavior

USER / REQUEST TEMPLATE
│
├── Task instructions
├── Context
├── Retrieved information
├── Examples (optional → few-shot)
├── Current input
└── Required output

REASONING STRATEGY
│
├── Direct response → simple task
└── Deliberate reasoning → complex task

Anthropic’s current guidance recommends giving Claude clear, explicit instructions, including desired output format and constraints. It also recommends structured prompts when instructions, examples, context, and input need to be clearly separated.

Exam implication

Do not automatically solve every quality problem by:

• adding examples,
• asking Claude to reason longer,
• adding more system-prompt text,
• selecting a bigger model.

Instead diagnose the failure first.

---

3 Zero-Shot Prompting

3.1 What Is Zero-Shot Prompting?

Zero-shot prompting means asking Claude to perform the task without supplying demonstrations of the desired input/output behavior.

Example:

Classify the following support request into one of:

- Billing
- Technical Support
- Account Access
- Cancellation

Return only the category.

Request:
"I forgot my password and can no longer sign in."

Claude receives:

• an instruction,
• allowed categories,
• an input,

but no worked examples.

---

4 When Zero-Shot Is the Best Choice

Use zero-shot when:

1 The task is straightforward

Example:

Extract the invoice number from this text.

2 The categories are self-explanatory

Classify as Positive, Neutral, or Negative.

3 The required format is easy to describe

Return JSON with:
customer_id
issue_type
priority

4 Additional examples would add unnecessary tokens

If Claude already understands the task reliably, examples create:

• additional token consumption,
• maintenance overhead,
• possible unwanted pattern imitation.

---

5 Zero-Shot Example — Enterprise Scenario

Suppose an e-commerce platform receives:

Customer:
"I received my package, but one of the items was damaged."

Prompt:

You classify customer requests.

Choose exactly one category:

DELIVERY
DAMAGED_ITEM
RETURN
PAYMENT
OTHER

Return only the category.

<request>
{{customer_request}}
</request>

Expected:

DAMAGED_ITEM

No examples are necessary because the classification boundary is clear.

---

6 Zero-Shot Strengths and Weaknesses

Strength	Why It Matters
Simple	Easy to design
Low token usage	Better cost/latency
Easy to maintain	No example library
Easy to update	Change instructions rather than examples

But zero-shot becomes weaker when:

• categories overlap,
• business definitions differ from ordinary meanings,
• output style is unusual,
• edge cases dominate,
• desired behavior is difficult to explain precisely.

That is the point where few-shot prompting becomes useful.

---

7 Few-Shot Prompting

7.1 What Is Few-Shot Prompting?

Few-shot prompting gives Claude representative input/output examples before asking it to handle a new case.

Anthropic currently describes examples as one of the most reliable ways to steer output format, tone, structure, accuracy, and consistency. Its guidance recommends relevant, diverse, well-structured examples and currently suggests roughly 3–5 examples as a useful starting point.

---

8 When Few-Shot Is the Best Technique

This is extremely important for CCAR-P.

Use few-shot when:

1 The desired behavior is easier to SHOW than describe

Suppose:

Premium customers with payment failures should be escalated,
except expired-card failures should be handled automatically,
unless the account has more than two previous failures...

You could keep adding prose.

Or demonstrate several representative cases.

2 Classification boundaries are ambiguous

Example:

A message says:

“The system crashes every time I attempt to update my credit card.”

Is this:

• Billing?
• Technical issue?

Your organization’s desired classification might be Technical Support even though the subject involves payment.

Examples teach Claude your organization’s interpretation.

3 Output format is unusual

This exact reasoning pattern appears in both supplied CCAR-P practice exams.

If the requirement is:

“Produce output in an unusual format that is difficult to describe.”

The likely answer is:

Few-shot prompting.

Why?

Examples communicate:

• formatting,
• ordering,
• punctuation,
• tone,
• nesting,
• labels,
• exceptions,

more effectively than a lengthy textual description.

4 Tone/style needs consistency

For example:

Customer complaint:
"This software is useless and your support is terrible."

Desired response:
"I understand how frustrating this experience has been. Let's get the immediate problem resolved first..."

A few carefully selected examples can establish the desired response style.

---

9 Few-Shot Example

Without examples

Classify the request as SIMPLE_RETURN or COMPLEX_RETURN.

Request:
"The jacket doesn't fit and I want another size."

“Complex” versus “simple” is underspecified.

With examples

Classify requests as SIMPLE_RETURN or COMPLEX_RETURN.

<examples>

<example>
<input>
The shirt is too small. Can I exchange it for medium?
</input>
<output>
SIMPLE_RETURN
</output>
</example>

<example>
<input>
I ordered three items. Two arrived damaged,
one is missing, and I was charged twice.
</input>
<output>
COMPLEX_RETURN
</output>
</example>

<example>
<input>
I want to return this unopened item within 14 days.
</input>
<output>
SIMPLE_RETURN
</output>
</example>

</examples>

<input>
{{request}}
</input>

Anthropic recommends separating examples and other components cleanly, including with XML-style tags where they improve parsing clarity.

---

10 Good vs Bad Few-Shot Examples

Examples are not automatically beneficial.

Poor example set

Example 1: easy billing issue
Example 2: easy billing issue
Example 3: easy billing issue
Example 4: easy billing issue

Claude may learn an overly narrow pattern.

Better example set

Include:

• normal case,
• ambiguous case,
• edge case,
• negative case,
• potentially confusing boundary case.

Anthropic specifically recommends examples that are relevant and diverse, rather than repeatedly illustrating essentially the same case.

---

11 Critical Exam Trap: Few-Shot Is NOT Chain-of-Thought

Consider:

An assistant must classify ambiguous requests. Written rules don’t fully communicate the distinction, but several representative examples would make the intended behavior obvious.

Possible answers:

A. Chain-of-thought B. Bigger Claude model C. Few-shot prompting D. Longer system prompt

Correct: C — Few-shot

Why?

The problem is:

“Claude doesn’t understand our decision boundary.”

Not:

“Claude cannot reason through the problem.”

Remember

Demonstrating judgment → Few-shot Increasing reasoning depth → Chain-of-thought

This distinction appears explicitly in the supplied practice exams.

---

12 Chain-of-Thought Prompting

12.1 What Does It Mean?

Traditional chain-of-thought prompting encourages the model to perform intermediate reasoning before producing the final conclusion.

Conceptually:

Problem
  ↓
Analyze relevant facts
  ↓
Work through dependencies
  ↓
Check assumptions
  ↓
Reach conclusion

It is useful for problems where a direct answer is less reliable than deliberate reasoning.

---

13 When Chain-of-Thought / Reasoning Helps

Use deliberate reasoning for:

• multi-step calculations,
• architectural trade-offs,
• constraint satisfaction,
• troubleshooting,
• complex policy interpretation,
• planning,
• dependency analysis,
• reasoning across tool results.

Anthropic’s current documentation says thinking capabilities are particularly valuable for complex multistep reasoning and reasoning that needs to happen around tool interactions.

---

14 Example: Direct Prompt vs Reasoning

Zero-shot/direct

Which hosting option should we use?

Too vague.

Structured reasoning task

Evaluate the two architecture options against:

1. p95 latency under 2 seconds
2. maximum infrastructure budget of $15,000/month
3. HIPAA requirements
4. 99.9% availability
5. 10,000 concurrent users

Identify the binding constraints,
compare the alternatives,
and recommend the best architecture.

State your final recommendation separately.

The task requires reasoning because several constraints interact.

---

15 Important 2026 Update: Don’t Memorize “Always Say Think Step by Step”

This deserves special attention because the exam blueprint uses the phrase chain-of-thought, but Claude’s modern reasoning capabilities are more sophisticated than traditional prompt recipes.

Anthropic’s current guidance recommends general reasoning instructions over overly prescriptive hand-written reasoning steps in many cases. Modern Claude models can use built-in/adaptive thinking, with reasoning depth influenced by the task and model configuration. Anthropic still documents manual CoT prompting as a fallback when thinking is disabled.

So distinguish:

Exam concept

Chain-of-thought =
encourage deliberate reasoning for difficult multistep problems

from:

Production implementation

Modern Claude reasoning may use:
- model-native thinking
- adaptive thinking
- effort controls
- high-level reasoning instructions
- or manual CoT where appropriate

Exam rule

If the scenario says:

“A genuinely difficult multi-step reasoning problem needs more reliable reasoning.”

and the choices include:

• zero-shot,
• few-shot,
• chain-of-thought,

choose:

Chain-of-thought.

Both supplied practice exams test essentially this exact distinction.

---

16 Chain-of-Thought vs Few-Shot

This is probably the highest-value comparison to memorize.

Problem	Best Technique
Task is obvious	Zero-shot
Desired behavior needs demonstration	Few-shot
Output format is unusual	Few-shot
Classification boundaries are ambiguous	Few-shot
Claude must follow organizational examples	Few-shot
Complex multi-step logic	Chain-of-thought
Hard arithmetic/reasoning	Chain-of-thought
Complex architecture trade-offs	Chain-of-thought
Simple extraction	Zero-shot
Straightforward classification	Zero-shot

Memory trick

Zero-shot: Tell it.

Few-shot: Show it.

Chain-of-thought: Reason through it.

---

17 Can You Combine the Techniques?

Yes.

This is important at professional level.

An architecture problem isn’t always:

zero-shot OR few-shot OR chain-of-thought.

You can combine them.

For example:

SYSTEM
You are a financial policy analyst.

<instructions>
Evaluate applications according to the policy supplied below.
Never invent missing applicant data.
If a required fact is missing, return NEEDS_REVIEW.
</instructions>

<examples>
...
several representative policy decisions
...
</examples>

<policy>
...
</policy>

<application>
...
</application>

Evaluate the application carefully against the policy.
Return:
decision
supporting_policy
missing_information

Here we have:

• system prompt → standing role/behavior
• few-shot → decision-boundary demonstrations
• reasoning → policy evaluation
• structured output → predictable downstream integration

Professional architecture frequently combines techniques.

---

18 Where Does the System Prompt Fit?

The workbook makes a useful distinction:

Persistent, request-independent behavior belongs in the system prompt.

Anthropic similarly recommends using the system prompt to establish an appropriate role for Claude.

Think:

SYSTEM PROMPT
       ↓
Who Claude is
How Claude behaves generally
Standing rules
Persistent output conventions
Escalation behavior

versus:

USER / TEMPLATE
       ↓
What must be done now
Current input
Request-specific context

---

19 Example: System Prompt vs User Prompt

System

You are an enterprise customer-support assistant.

Your responsibilities:
- analyze customer issues accurately;
- use supplied customer records as the factual source;
- distinguish facts from assumptions;
- escalate when required information is missing;
- use concise, professional language.

Never claim an action was completed unless the corresponding
tool result confirms success.

User

Customer request:

<request>
{{customer_message}}
</request>

Customer record:

<customer>
{{customer_record}}
</customer>

Determine the appropriate next action.

This is much better than repeating all standing behavior in every user request.

---

20 System Prompt vs Prompt Template

A system prompt defines persistent behavior.

A template defines reusable request structure.

Example template:

<task>
Analyze the support case.
</task>

<context>
{{customer_context}}
</context>

<request>
{{customer_message}}
</request>

<output_format>
{
  "category": "...",
  "priority": "...",
  "recommended_action": "...",
  "reason": "..."
}
</output_format>

Values such as:

{{customer_context}}
{{customer_message}}

change per request.

The structure remains constant.

---

21 Why Templates Matter Architecturally

Templates improve:

• consistency,
• maintainability,
• reuse,
• testability,
• prompt versioning,
• separation between instructions and data.

This becomes important when multiple applications use Claude.

Instead of:

App A → Prompt copied manually
App B → Prompt copied manually
App C → Prompt copied manually

prefer a controlled reusable prompt strategy.

That connects directly with another Domain 2 blueprint objective: prompt reuse strategies.

---

22 Guardrails: Prompt Instructions Are NOT Security Controls

This is one of the most important CCAR-P concepts.

Suppose the system prompt says:

Never delete an account unless the user is authorized.

That is useful behavioral guidance.

But it is not sufficient authorization enforcement.

The workbook makes this distinction explicitly: persistent behavioral guidance can belong in the system prompt, but requirements that must hold even under prompt injection belong in enforced layers, such as authorization, harness controls, or approval workflows.

Wrong architecture

Claude
  ↓
"Please do not delete unauthorized accounts"
  ↓
DELETE ACCOUNT API

Better architecture

Claude
  ↓
Requests delete_account
  ↓
Authorization service
  ├── Authorized → Execute
  └── Unauthorized → Deny

---

23 Prompt Guardrail vs Enforced Guardrail

Requirement	Best Location
”Write professionally”	System prompt
”Ask for clarification when information is missing”	System prompt
”Return JSON”	Prompt/template/schema
”Use supplied policies”	Prompt
”Never reveal another customer’s records”	Authorization/data layer
”Only managers can issue refunds > $500”	Authorization layer
”Human approval required before wire transfer”	Workflow
”Never expose API credentials”	Architecture/secret management

Exam heuristic

If failure would create a security, authorization, regulatory, irreversible financial, or safety breach, don’t rely on a prompt alone.

---

24 Clear Instructions Come Before Fancy Prompting

A common mistake is immediately adding few-shot examples or chain-of-thought.

Anthropic recommends starting with clear and direct instructions, including explicit output requirements and constraints.

For example:

Weak

Analyze this ticket.

Better

Classify the ticket into exactly one of:

BILLING
ACCOUNT
TECHNICAL
CANCELLATION

Return JSON:

{
 "category": "",
 "confidence": ""
}

Before adding examples, determine whether clearer instructions already solve the problem.

---

25 Prompt Structure with XML Tags

Anthropic recommends XML-style structure when complex prompts combine multiple semantic components such as:

• instructions,
• context,
• examples,
• inputs,
• documents.

Example:

<instructions>
Classify the customer request.
</instructions>

<categories>
BILLING
ACCOUNT
TECHNICAL
CANCELLATION
</categories>

<examples>
...
</examples>

<customer_request>
{{request}}
</customer_request>

Why?

Without separation:

Instructions + policies + customer text + examples + documents

can become ambiguous.

With structure:

<instructions>...</instructions>
<policy>...</policy>
<input>...</input>

the semantic roles are much clearer.

---

26 What Prompt Engineering Cannot Fix

Another high-value exam concept:

Not every system problem is a prompt problem.

Anthropic explicitly recommends defining success criteria and evaluations before iterating on prompts, and notes that some failures are better addressed through model choice or another architectural change.

For example:

Problem	Better Solution
Missing current company information	Retrieval/RAG
Unauthorized tool access	Authorization
Excessive latency	Model/architecture optimization
Huge repeated static prefix	Prompt caching
Missing database access	Integration/tool
Long-session context degradation	Context management
Difficult classification semantics	Few-shot prompting
Complex reasoning failures	Reasoning/CoT

Exam trap

Question:

Claude does not know the company’s latest refund policy.

Wrong:

Use chain-of-thought.

Correct:

Provide/retrieve the policy.

Reasoning cannot create missing knowledge.

---

27 Prompt Engineering Decision Framework

For the exam, use this sequence:

START
  │
  ▼
Does Claude have the information needed?
  │
  ├─ NO → Fix context / retrieval / tools
  │
  ▼ YES
Is the task straightforward and clearly defined?
  │
  ├─ YES → ZERO-SHOT
  │
  ▼ NO
Would examples clearly demonstrate expected behavior?
  │
  ├─ YES → FEW-SHOT
  │
  ▼ NO
Is the failure caused by difficult multi-step reasoning?
  │
  ├─ YES → REASONING / CHAIN-OF-THOUGHT
  │
  ▼
Evaluate model/task mismatch,
architecture, context, or workflow.

This is much more useful than memorizing definitions.

---

28 Failure Diagnosis — Exam-Focused

Symptom 1

Claude understands the categories but frequently confuses two organization’s internal categories.

Best first approach

Few-shot examples.

Why?

Your organization’s distinction needs demonstration.

Symptom 2

Claude performs simple tasks well but struggles with problems requiring multiple dependent logical steps.

Best approach

Chain-of-thought/reasoning.

Symptom 3

Claude gives poor output because the instructions say only:

Make this better.

Best approach

Improve the instructions first.

Not necessarily few-shot.

Symptom 4

Claude consistently fails because it does not know today’s product catalog.

Best approach

Retrieval/tool integration.

Not chain-of-thought.

Symptom 5

Every application call must use the same role and standing behavior.

Best approach

System prompt.

Symptom 6

Only authorized managers may issue high-value refunds.

Best approach

Authorization enforcement.

Not a system-prompt instruction.

---

29 Common CCAR-P Exam Traps

Trap 1 — “Few-shot improves everything”

No.

Examples add:

• context,
• tokens,
• maintenance,
• possible unintended pattern learning.

Use them where demonstrations solve a real ambiguity.

Trap 2 — “Chain-of-thought is always better”

No.

Reasoning adds computational work and potentially latency/cost. Modern Anthropic guidance recommends applying thinking where it meaningfully improves complex tasks, rather than indiscriminately forcing it on simple requests.

Don’t make:

"Extract email address"

into a deep reasoning task.

Trap 3 — “Use chain-of-thought for ambiguous classifications”

Usually not.

If intended classifications are organization-specific:

Few-shot is typically stronger.

This distinction appears directly in the supplied practice exams.

Trap 4 — “A system prompt is an enforcement mechanism”

Wrong.

System prompts guide behavior.

Authorization systems enforce capability.

Trap 5 — “A bigger model fixes poor prompting”

Possibly—but that’s not the correct first diagnosis.

If the prompt does not explain the task or provide required context, bigger-model selection may simply make an unnecessarily expensive bad design.

Trap 6 — “More prompt = better prompt”

No.

A long prompt can introduce:

• contradictory instructions,
• irrelevant context,
• token cost,
• maintenance difficulty.

Clarity beats verbosity.

Trap 7 — “Use CoT when the model lacks facts”

Reasoning ≠ knowledge.

If facts are missing, retrieve them.

---

30 Zero-Shot vs Few-Shot vs Chain-of-Thought — Master Comparison

Dimension	Zero-Shot	Few-Shot	Chain-of-Thought / Reasoning
Examples supplied	No	Yes	Not necessarily
Primary goal	Direct task completion	Demonstrate desired behavior	Improve complex reasoning
Best for	Clear tasks	Ambiguous/custom behaviors	Multistep problems
Token overhead	Lowest	Higher	Usually higher
Maintenance	Lowest	Example set must be maintained	Reasoning strategy/config
Classification	Clear categories	Ambiguous categories	Only if classification itself requires complex reasoning
Unusual formatting	Possible	Excellent	Usually unnecessary
Complex logic	Limited	Examples may help	Best fit
Main risk	Under-specification	Bad examples bias behavior	Cost/latency/overthinking

---

31 Prompt Engineering Escalation Ladder

A practical optimization strategy:

Level 1 — Clear zero-shot prompt

Instruction + context + output definition

↓

If insufficient:

Level 2 — Improve structure

Role
Instructions
Context
Input
Output requirements

↓

If behavior still ambiguous:

Level 3 — Add few-shot examples

Representative + edge + boundary cases

↓

If complex reasoning remains unreliable:

Level 4 — Add reasoning / thinking strategy

↓

If still insufficient:

Level 5 — Investigate

• context quality,
• model fit,
• tools,
• RAG,
• decomposition,
• workflow,
• evaluation results.

This is a much more architecturally mature strategy than blindly creating an enormous prompt.

---

32 How Prompt Engineering Connects to Evaluation

Prompt engineering without evaluation is guessing.

Anthropic recommends establishing success criteria and empirical tests before systematic prompt improvement.

For example:

Baseline zero-shot
Accuracy: 83%

↓ add 4 representative examples

Few-shot
Accuracy: 94%
Latency: +80 ms
Cost: +6%

↓ decision

Use few-shot because the accuracy gain
justifies the small cost increase.

That is the kind of reasoning expected from a professional architect.

Not:

“Few-shot is considered better.”

But:

“Few-shot improved the specific failing behavior sufficiently to justify its cost and complexity.”

---

33 The Professional-Level Architecture View

Consider a production financial assistant:

┌──────────────────────────────┐
│        SYSTEM PROMPT         │
│ role + standing behavior     │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│       PROMPT TEMPLATE        │
│ instructions + variables     │
│ structured sections          │
└──────────────┬───────────────┘
               │
               ├── Few-shot examples
               │
               ├── Retrieved context
               │
               ▼
┌──────────────────────────────┐
│            CLAUDE            │
│ direct or deeper reasoning   │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│       OUTPUT VALIDATION      │
│ schema / policy checks       │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│     AUTHORIZATION / HUMAN    │
│        APPROVAL GATE         │
└──────────────────────────────┘

This illustrates a very important exam principle:

Prompt engineering is one layer of the architecture—not the architecture itself.

---

34 Prompt Engineering Anti-Patterns

❌ Mega-prompt

Hundreds of loosely organized instructions copied into one block.

Better: modular structure and explicit sections.

❌ Example overload

30 examples for a simple classification task.

Better: a small representative, diverse set.

Anthropic’s current guidance suggests approximately 3–5 examples as a good starting point.

❌ Prompt-only security

Never execute dangerous actions.

Better: remove or authorize dangerous capabilities outside the model.

❌ Reasoning every request

Think deeply through every request.

even for:

Extract account number.

Better: reserve deeper thinking for problems where it materially improves results.

❌ Examples with accidental bias

All examples:

Premium customer → escalate
Premium customer → escalate
Premium customer → escalate

Claude may infer:

Premium → always escalate

even when that wasn’t intended.

Use diverse examples.

---

35 Exam-Focused “Which Technique?” Cheat Sheet

When you see:

“No examples are necessary”

→ Zero-shot

”Straightforward instruction”

→ Zero-shot

”A handful of examples would clarify”

→ Few-shot

”Hard to explain in words”

→ Few-shot

”Unusual output format”

→ Few-shot

”Representative edge cases”

→ Few-shot

”Complex multi-step reasoning”

→ Chain-of-thought / thinking

”Needs deliberate analysis”

→ Chain-of-thought / reasoning

”Same persona every request”

→ System prompt

”Persistent behavioral instructions”

→ System prompt

”Must absolutely prevent unauthorized action”

→ Enforced guardrail / authorization

”Model lacks information”

→ Context / retrieval, not prompting technique

---

36 Two Recommended Exercises

The linked Foundation-level guide uses a Build Exercise. For CCAR-P preparation, I would replace it with more architecture-oriented exercises. The linked guide is useful stylistically because it builds concepts progressively with explanations and exam-oriented distinctions, but CCAR-P candidates need more emphasis on architectural judgment.

Exercise 1 — Prompt Technique Selection Lab

You have a support assistant with four problems:

Problem A

Straightforward ticket categories are being classified correctly 98% of the time.

Question: Add few-shot examples?

Answer: No. Keep zero-shot unless evaluation shows a material need.

Problem B

“Billing Dispute” and “Payment Technical Failure” are repeatedly confused because internal definitions differ from normal usage.

Solution: Add diverse few-shot examples, especially boundary cases.

Problem C

The assistant must analyze six dependent policy rules before determining eligibility.

Solution: Use a reasoning / chain-of-thought strategy.

Problem D

The assistant doesn’t know a policy released yesterday.

Solution: Retrieval, not additional reasoning.

Learning objective

For every failure, identify whether the solution is:

ZERO-SHOT
FEW-SHOT
REASONING
CONTEXT
SYSTEM PROMPT
GUARDRAIL
MODEL

This is very close to how scenario questions test judgment.

---

37 Exercise 2 — Prompt Architecture Review

Review:

You are a bank assistant.

Never approve an unauthorized transaction.
Always be helpful.

Here are 20 examples...

Here are all customer policies...

Think step by step about everything.

User:
{{request}}

Identify at least five problems.

Expected observations

1. Authorization cannot be guaranteed by prompt text.
2. Examples may be excessive or poorly selected.
3. Static policy should be managed as context/retrieval where appropriate.
4. “Think step by step about everything” may waste reasoning resources.
5. Instructions/context/examples should be structured clearly.
6. Current input should be clearly separated from trusted instructions.
7. Prompt should have measurable success criteria and an eval set.
8. Persistent behavior and dynamic request context should be separated.

This exercise tests architecture rather than prompt syntax.

---

38 Five CCAR-P-Style Practice Questions

These are newly created practice questions based on the official objective and the reasoning style evident in the supplied materials; they are not actual exam questions. The official guide says its sample items are illustrative of style and cognitive level rather than live exam-bank questions.

Question 1 — Zero-Shot vs Few-Shot

A SaaS company needs Claude to classify incoming requests into SALES, SUPPORT, and BILLING. The category descriptions are simple and a representative evaluation shows 97% accuracy using only clear instructions. An architect proposes adding ten examples to improve the prompt further.

What is the BEST approach?

A. Add ten examples because few-shot prompting always improves classification. B. Keep the zero-shot prompt unless evaluation identifies a meaningful failure that examples solve. C. Replace the prompt with chain-of-thought prompting. D. Upgrade to the most capable Claude model.

Correct Answer: B

Why?

The existing zero-shot prompt already meets the task effectively. Adding examples introduces token and maintenance overhead without demonstrated value.

Why the others are wrong

A: Few-shot is not automatically superior.

C: There is no difficult multi-step reasoning problem.

D: No model mismatch has been established.

Exam lesson

Do not optimize a prompt without a demonstrated problem.

Question 2 — Few-Shot Boundary Cases

A healthcare platform classifies requests as CLINICAL_QUESTION, ADMINISTRATIVE, or URGENT_ESCALATION. Written definitions are clear to domain experts, but Claude repeatedly misclassifies cases near the boundary between CLINICAL_QUESTION and URGENT_ESCALATION. Several carefully selected examples clearly demonstrate the distinction.

What should the architect try first?

A. Add representative few-shot examples, including boundary cases. B. Ask Claude to reason step-by-step about every request. C. Increase context-window capacity. D. Add the categories to a retrieval database.

Correct Answer: A

Examples directly address the missing information: how the organization distinguishes ambiguous cases.

Anthropic recommends examples for steering output and consistency, with relevance and diversity important to avoid accidental pattern learning.

Exam lesson

Ambiguous behavioral boundary + examples clarify it = few-shot.

Question 3 — Chain-of-Thought / Reasoning

A financial-services application must evaluate a proposed transaction against six policy conditions. Later conditions depend on conclusions reached from earlier conditions, and simple direct prompting frequently produces inconsistent answers.

Which prompt-engineering approach most directly addresses the problem?

A. Add examples showing the desired JSON output. B. Use deliberate reasoning / chain-of-thought for the multistep analysis. C. Move the instructions into the user message. D. Increase the number of retrieved documents.

Correct Answer: B

The failure concerns reasoning depth across dependent steps.

Anthropic’s current documentation identifies thinking as particularly useful for complex multistep reasoning.

Exam lesson

Complex dependent reasoning = CoT/reasoning, not merely examples.

Question 4 — System Prompt vs Guardrail

A refund assistant should maintain a professional persona on every request. Only supervisors may approve refunds exceeding $1,000.

Where should these two requirements be implemented?

A. Put both requirements in the system prompt. B. Put the persona in few-shot examples and the refund rule in chain-of-thought. C. Put the standing persona in the system prompt and enforce the refund limit through authorization/workflow controls. D. Put both requirements in the user message.

Correct Answer: C

Persistent request-independent behavior is appropriate for the system prompt.

But a financial authorization requirement must be enforced outside the model, not merely requested through advisory prompt text.

Exam lesson

Behavior → prompt. Permission → enforcement.

Question 5 — Diagnose Before Prompting

A legal research assistant produces logically coherent answers but repeatedly cites outdated internal policies. The policies are updated every week. The team proposes adding the instruction:

Think carefully and ensure you use the newest policy.

What should the architect recommend?

A. Use chain-of-thought to reason harder about policy freshness. B. Add five examples containing recent policies. C. Implement retrieval of current authoritative policies and provide the relevant material in context. D. Add a stronger system prompt saying outdated policies must never be used.

Correct Answer: C

The problem is missing/fresh information, not reasoning capability.

No amount of prompt sophistication allows Claude to reliably reason from information it does not have.

Exam lesson

Knowledge problem → context/retrieval. Reasoning problem → reasoning technique.

---

39 Last-Minute Revision Table

Signal in Question	Think
”straightforward task”	Zero-shot
”clear instruction is sufficient”	Zero-shot
”representative examples”	Few-shot
”hard-to-describe behavior”	Few-shot
”unusual output format”	Few-shot
”ambiguous categories”	Few-shot
”multi-step reasoning”	Chain-of-thought
”dependent logical steps”	Chain-of-thought
”persistent persona”	System prompt
”standing behavior”	System prompt
”specific current request”	User/template
”must never be allowed”	Enforced guardrail
”unauthorized action”	Authorization
”missing current facts”	RAG/context/tool
”repeated large static prompt”	Prompt caching
”prompt change”	Version + evaluate

The official CCAR-P sample questions themselves demonstrate this broader exam philosophy: identify the mechanism that directly solves the stated architectural problem, rather than selecting something generally beneficial.

---

40 The 10 Rules to Remember for Maximum Marks

1. Start zero-shot when the task is clear and evaluation shows it works.
2. Use few-shot when showing is easier than explaining.
3. Use diverse boundary examples, not ten copies of the same easy case.
4. Use reasoning/CoT for genuinely difficult multi-step problems.
5. Don’t force expensive reasoning onto simple extraction/classification tasks.
6. System prompts hold persistent, request-independent behavior.
7. Templates hold reusable structure plus dynamic request data.
8. Prompts guide behavior; they do not replace authorization or security controls.
9. Missing knowledge is a context/retrieval problem, not a reasoning problem.
10. Evaluate every prompt change—don’t judge improvements from one impressive example.

Anthropic’s current prompt-engineering guidance strongly supports the last point: establish success criteria and empirical evaluation before optimizing prompts.

One-Sentence Exam Memory Formula

Tell it → Zero-shot. Show it → Few-shot. Make it reason → Chain-of-thought. Keep it persistent → System prompt. Must enforce it → Guardrail outside the prompt.

That formula covers most of the distinctions candidates are likely to face for this CCAR-P objective.