6 виробничих сценаріїв екзамену CCA-F

На кожній сесії випадково обирається 4 з 6 сценаріїв. Знайомство з усіма — перевага.

Сценарій 1

Customer Support Resolution Agent

Агент підтримки на Claude Agent SDK обробляє повернення, спори по платежах і питання акаунтів. Доступ до бекенду через MCP-інструменти get_customer, lookup_order, process_refund, escalate_to_human. Ціль — 80%+ first-contact resolution.

Приклади питань

Домен 11 / 2
Дані продакшену показують: у 12% випадків агент пропускає get_customer і викликає lookup_order лише за іменем клієнта, що інколи призводить до помилкової ідентифікації акаунта й неправильних повернень. Яка зміна найефективніше вирішить цю проблему надійності?
AДодати programmatic prerequisite, який блокує виклики lookup_order і process_refund, доки get_customer не поверне верифікований customer ID
BПідсилити system prompt вимогою, що верифікація через get_customer обов'язкова перед будь-якими операціями із замовленнями
CДодати few-shot приклади, де агент завжди викликає get_customer першим, навіть коли клієнт сам назвав номер замовлення
DВпровадити routing-класифікатор, який вмикає лише підмножину інструментів під тип запиту
✓ A — Коли критична бізнес-логіка вимагає певної послідовності (верифікація перед поверненням коштів), programmatic enforcement дає детерміновані гарантії, яких prompt-підходи (B, C) дати не можуть через ненульову ймовірність недотримання. D вирішує доступність інструментів, а не їх порядок.
Домен 22 / 2
Логи показують, що агент часто кличе get_customer на запити про замовлення (напр. «перевір моє замовлення #12345») замість lookup_order. Обидва інструменти мають мінімальні описи («Retrieves customer information» / «Retrieves order details») і приймають схожі формати ідентифікаторів. Який найефективніший перший крок?
AРозширити опис кожного інструмента: формати входу, приклади запитів, edge cases і межі застосування відносно схожих інструментів
BДодати 5–8 few-shot прикладів у system prompt, що скеровують order-запити на lookup_order
CРеалізувати routing-шар, що парсить ввід і наперед обирає інструмент за ключовими словами
DОб'єднати обидва інструменти в один lookup_entity, що сам визначає бекенд
✓ A — Описи інструментів — основний механізм вибору для LLM. За мінімальних описів моделі бракує контексту, щоб розрізнити схожі інструменти. B додає токени, не усуваючи причину; C — over-engineering, що обходить розуміння моделі; D — валідна, але важча архітектурна зміна, ніж потрібно для «першого кроку».
Практика за сценарієм 1 →
Сценарій 2

Code Generation with Claude Code

Команда використовує Claude Code для генерації коду, рефакторингу, дебагу й документації. Потрібна інтеграція у воркфлоу: custom slash commands, CLAUDE.md, та розуміння plan mode vs direct execution.

Приклади питань

Домен 31 / 2
Ви хочете створити custom-команду /review, що запускає стандартний чек-лист код-рев'ю команди. Вона має бути доступна кожному розробнику після clone/pull репозиторію. Де створити файл команди?
AУ директорії .claude/commands/ у репозиторії проєкту
BУ ~/.claude/commands/ у домашній директорії кожного розробника
CУ файлі CLAUDE.md у корені проєкту
DУ .claude/config.json з масивом commands
✓ A — Project-scoped slash-команди зберігають у .claude/commands/ репозиторію — вони версіонуються й доступні всім після clone/pull. B — це особисті команди (не шеряться); CLAUDE.md (C) — для контексту, не для команд; D описує неіснуючий у Claude Code механізм.
Домен 32 / 2
Вам доручили реструктуризувати моноліт у мікросервіси: зміни в десятках файлів і рішення про межі сервісів та залежності модулів. Який підхід обрати?
AУвійти в plan mode: дослідити кодбазу, зрозуміти залежності й спроєктувати підхід ще до змін
BПочати з direct execution й міняти інкрементально, дозволивши реалізації виявити природні межі
CDirect execution з повними наперед інструкціями, як саме структурувати кожен сервіс
DПочати в direct execution і перемкнутись у plan mode лише якщо виникне несподівана складність
✓ A — Plan mode створений саме для масштабних змін, кількох валідних підходів та архітектурних рішень. Він дозволяє безпечно дослідити код перед комітом до змін. B ризикує дорогими переробками; C припускає готову відповідь без дослідження; D ігнорує, що складність уже задана вимогами.
Практика за сценарієм 2 →
Сценарій 3

Multi-Agent Research System

Coordinator-агент делегує спеціалізованим subagent'ам: пошук у вебі, аналіз документів, синтез і генерація звіту. Система готує повні звіти з цитуванням джерел.

Приклади питань

Домен 11 / 2
Запустивши систему на темі «вплив AI на креативні індустрії», ви бачите: усі subagent'и відпрацювали успішно, але фінальні звіти охоплюють лише візуальне мистецтво й повністю пропускають музику, письменство та кіно. У логах coordinator'а: він розбив тему на «AI in digital art», «AI in graphic design», «AI in photography». Найімовірніша корінна причина?
AДекомпозиція задачі coordinator'ом надто вузька — призначення subagent'ам не покривають усіх релевантних доменів теми
BSynthesis-агенту бракує інструкцій виявляти прогалини покриття в отриманих знахідках
CЗапити web-search агента недостатньо широкі й їх треба розширити
DDocument-аналіз агент відфільтровує не-візуальні джерела через надто жорсткі критерії релевантності
✓ A — Логи прямо показують причину: coordinator розклав «креативні індустрії» лише на візуальні підтеми, пропустивши музику/письменство/кіно. Subagent'и коректно зробили те, що їм призначили. B, C, D помилково звинувачують нижчі агенти, які працюють у межах призначеного scope.
Домен 52 / 2
Web-search subagent впадає в timeout на складній темі. Ви проєктуєте, як ця інформація про збій тече назад до coordinator'а. Який підхід до error propagation найкраще вмикає інтелектуальне відновлення?
AПовернути coordinator'у структурований error-контекст: тип збою, який запит пробували, будь-які partial results і можливі альтернативні підходи
BРеалізувати retry з exponential backoff усередині subagent'а й повернути лише «search unavailable» після вичерпання спроб
CПерехопити timeout і повернути порожній результат, позначений як успішний
DПрокинути timeout-виняток у top-level handler, що завершує весь research-воркфлоу
✓ A — Структурований error-контекст дає coordinator'у дані для розумного рішення (ретрай з модифікацією, альтернатива, чи продовжити з partial results). Загальний статус (B) ховає контекст; «успіх» при збої (C) приховує помилку; завершення всього воркфлоу (D) надмірне.
Практика за сценарієм 3 →
Сценарій 4

Developer Productivity with Claude

Агент допомагає інженерам досліджувати незнайомі кодбази, розбирати legacy, генерувати boilerplate. Використовує built-in tools (Read, Write, Bash, Grep, Glob) та MCP-сервери.

Приклади питань

Домен 21 / 2
Інженер просить знайти всі місця виклику конкретної функції по кодбазі. Який built-in інструмент обрати?
AGrep — пошук за вмістом файлів (імена функцій, повідомлення помилок, import'и)
BGlob — пошук файлів за патерном імені/розширення
CRead — читати кожен файл цілком по черзі
DBash із інтерактивним редактором
✓ A — Grep призначений для пошуку за вмістом коду (напр. усі виклики функції). Glob (B) шукає файли за патерном імені; Read (C) читає вміст конкретного файлу, не шукає по всіх; Bash-редактор (D) недоречний.
Домен 22 / 2
Потрібно знайти всі тестові файли за патерном **/*.test.tsx по проєкту. Який інструмент пасує?
AGlob — пошук шляхів файлів за патерном імені/розширення
BGrep — пошук за вмістом усередині файлів
CEdit — точкова зміна за унікальним текстом
DWrite — створення нових файлів
✓ A — Glob знаходить файли за патернами імен (напр. **/*.test.tsx). Grep (B) — для вмісту; Edit (C) і Write (D) — для модифікації/створення, не для пошуку.
Практика за сценарієм 4 →
Сценарій 5

Claude Code for Continuous Integration

Claude Code інтегрований у CI/CD: автоматичні code review, генерація тестів, фідбек на pull request'и. Потрібні промпти з actionable-фідбеком і мінімумом false positives.

Приклади питань

Домен 31 / 2
Ваш pipeline-скрипт запускає claude "Analyze this PR for security issues", але job висить нескінченно — Claude Code чекає на інтерактивний ввід. Який правильний підхід для автоматизованого пайплайну?
AДодати прапорець -p: claude -p "Analyze this PR for security issues"
BВиставити змінну оточення CLAUDE_HEADLESS=true перед запуском
CПеренаправити stdin з /dev/null
DДодати прапорець --batch
✓ A — Прапорець -p (--print) — задокументований спосіб запуску Claude Code в неінтерактивному режимі: обробляє промпт, друкує в stdout і виходить. CLAUDE_HEADLESS (B) і --batch (D) — неіснуючі; редирект stdin (C) — обхід, що не відповідає синтаксису Claude Code.
Домен 42 / 2
Команда хоче зменшити витрати на API. Зараз real-time виклики живлять два воркфлоу: (1) блокуючий pre-merge check, який має завершитись до merge, і (2) звіт по tech debt, що генерується вночі для ранкового перегляду. Менеджер пропонує перевести обидва на Message Batches API заради 50% економії. Як оцінити?
AПеревести на batch лише звіти по tech debt; для pre-merge checks лишити real-time
BПеревести обидва на batch зі status polling
CЛишити real-time для обох, щоб уникнути проблем із порядком результатів
DПеревести обидва на batch із timeout-fallback на real-time
✓ A — Batches API дає 50% економії, але час обробки — до 24 годин без гарантії latency. Це не годиться для блокуючого pre-merge, але ідеально для нічних звітів. B покладається на «зазвичай швидше» — неприйнятно для блокуючого; C — хибне уявлення (результати корелюються через custom_id); D — зайва складність.
Практика за сценарієм 5 →
Сценарій 6

Structured Data Extraction

Система витягує дані з неструктурованих документів, валідує через JSON-схеми й тримає високу точність. Має акуратно обробляти edge cases й інтегруватися з downstream-системами.

Приклади питань

Домен 41 / 2
Ваша система екстракції інколи повертає синтаксично невалідний JSON, що ламає downstream. Який підхід найнадійніше гарантує schema-compliant вивід без JSON-синтаксичних помилок?
ATool use (tool_use) з JSON-схемою як вхідними параметрами інструмента, з якого витягують структуровані дані
BПросити модель «повертати валідний JSON» у system prompt і парсити відповідь
CРегулярками лагодити невалідний JSON постфактум
DЗнизити temperature до нуля, щоб JSON завжди був валідним
✓ A — tool_use із JSON-схемою — найнадійніший спосіб гарантованого schema-compliant виводу, що усуває синтаксичні помилки JSON. Прохання в промпті (B) ймовірнісне; полагодження регулярками (C) крихке; temperature (D) не гарантує валідності схеми.
Домен 42 / 2
Деякі вихідні документи не містять певних полів, а модель вигадує значення, щоб задовольнити required-поля схеми. Як це усунути?
AЗробити такі поля optional/nullable, щоб модель повертала null замість фабрикації, коли інформації немає
BЛишити поля required, але просити модель «не вигадувати»
CВидалити ці поля зі схеми взагалі
DПідвищити max_tokens, щоб модель знайшла відсутні значення
✓ A — Поля, яких може не бути в джерелі, проєктують optional/nullable — це не змушує модель фабрикувати значення під required. Прохання «не вигадувати» (B) ймовірнісне; видалення полів (C) втрачає дані там, де вони є; max_tokens (D) не створить відсутню інформацію.
Практика за сценарієм 6 →
Запустити тренажер →Домени екзамену