Açıklamalı Örnek Sorular, Pratik Egzersizler ve Son Kontrol Listesi

Bu ders, kursun son halkası: resmî hazırlık rehberindeki 12 açıklamalı örnek soruyu (final simülasyondaki 76 sorudan ayrı, sınav yazarlarının “böyle düşünün” diye verdiği referans sorular), 4 pratik egzersizi, kapsam dışı konular listesini ve hazırlık önerilerini içerir. Final simülasyonu çözmeden önce buradaki 12 soruyu çöz: her birinin gerekçesi, sınavın tüm sorularında geçerli olan karar prensiplerini öğretir.

Neden bu ders sınavda fark yaratır

Sınav sorularının neredeyse tamamı “hangisi en etkili / en güvenilir / ilk adım?” kalıbındadır — yani dört şıkkın hepsi kısmen makuldür, doğru cevap prensip bilgisiyle seçilir. Bu dersteki 12 soru, o prensipleri tek tek izole eder: deterministik guarantee > prompt, tool description = birincil seçim mekanizması, planning mode tetikleyicileri, batch API trade-off’u, attention dilution. Bu prensipleri ezberlemek yerine gerekçeleriyle sindirirsen, hiç görmediğin sorularda da doğru şıkkı bulursun.

12 Açıklamalı Örnek Soru

Örnek 1 (Scenario: Customer Support Agent)

Situation: Data shows that in 12% of cases the agent skips get_customer and calls lookup_order using only the customer’s name, which leads to incorrect refunds.

Which change is most effective?

A) Add a programmatic precondition that blocks lookup_order and process_refund until an ID is obtained from get_customer (Correct)
B) Improve the system prompt
C) Add few-shot examples
D) Implement a routing classifier

Gerekçe: Kritik iş mantığı belirli bir tool sırası gerektiriyorsa, yazılım deterministik garanti sağlar; prompt tabanlı yaklaşımlar (B, C) sağlayamaz. D, erişilebilirlik problemini çözer — tool sıralamasını değil. Bu prensip sınavda defalarca test edilir: enforcement gerekiyorsa kod, rehberlik yeterliyse prompt.

Örnek 2 (Scenario: Customer Support Agent)

Situation: The agent often calls get_customer instead of lookup_order for order-related questions. Tool descriptions are minimal and similar.

What is the first step?

A) Few-shot examples
B) Expand each tool’s description with input formats, examples, and boundaries (Correct)
C) Add a routing layer
D) Merge the tools

Gerekçe: Tool description’lar, modelin birincil tool seçim mekanizmasıdır. Bu, en düşük eforlu ve en yüksek etkili düzeltmedir. A, kök nedene dokunmadan token ekler. C overengineering’dir. D, gereğinden fazla efor ister. “İlk adım” soran sorularda daima en düşük maliyetli kök-neden müdahalesini seç.

Örnek 3 (Scenario: Customer Support Agent)

Situation: The agent resolves only 55% of issues with a target of 80%. It escalates simple cases and tries to handle complex policy exceptions autonomously.

How do you improve calibration?

A) Add explicit escalation criteria with few-shot examples (Correct)
B) Self-rated confidence (1–10) with automatic escalation
C) A separate classifier trained on historical data
D) Sentiment analysis

Gerekçe: Kök neden belirsiz karar sınırlarıdır; A bunu doğrudan ele alır. B güvenilmezdir — model kendinden emin şekilde yanlış olabilir (self-rated confidence sınavın klasik tuzak şıkkıdır). C overengineering. D başka bir problemi çözer: duygu durumu ≠ karmaşıklık.

Örnek 4 (Scenario: Code Generation with Claude Code)

Situation: You need a custom /review command for standard code review that is available to the whole team when they clone the repository.

Where should you create the command file?

A) .claude/commands/ in the project repository (Correct)
B) ~/.claude/commands/
C) Root CLAUDE.md
D) .claude/config.json

Gerekçe: Proje içindeki .claude/commands/ versiyon kontrolündedir ve repo’yu klonlayan herkese otomatik ulaşır. B kişisel komutlar içindir (takıma dağılmaz). C talimat dosyasıdır, komut tanımı değil. D diye bir dosya yoktur. “Takımla paylaşılacak mı?” sorusu proje dizini vs home dizini ayrımını belirler.

Örnek 5 (Scenario: Code Generation with Claude Code)

Situation: You need to restructure a monolith into microservices (dozens of files, service-boundary decisions).

What approach should you use?

A) Planning mode: explore the codebase, understand dependencies, design an approach (Correct)
B) Direct execution incrementally
C) Direct execution with detailed up-front instructions
D) Direct execution and switch to planning when it gets hard

Gerekçe: Planning mode tam olarak bunun için var: büyük değişiklik + birden fazla olası yaklaşım + mimari kararlar. B pahalı rework riski taşır. C, yapıyı zaten bildiğini varsayar. D reaktiftir — sorun çıktıktan sonra plana dönmek, baştan planlamaktan pahalıdır.

Örnek 6 (Scenario: Code Generation with Claude Code)

Situation: A codebase has different conventions across areas (React, API, database). Tests are co-located with code. You want conventions to be applied automatically.

What approach should you use?

A) .claude/rules/ files with YAML frontmatter and glob patterns (Correct)
B) Put everything in the root CLAUDE.md
C) Skills in .claude/skills/
D) CLAUDE.md in every directory

Gerekçe: .claude/rules/ + glob pattern (örn. **/*.test.tsx), dosya yoluna göre otomatik konvansiyon uygular — testler kodla iç içe dağıldığında ideal. B model çıkarımına güvenir. C manuel/talep üzerine tetiklenir. D, ilgili dosyalar çok sayıda dizine dağıldığında işlemez.

Örnek 7 (Scenario: Multi-agent Research System)

Situation: The system researches “AI impact on creative industries,” but reports cover only visual art. The coordinator decomposed the topic into: “AI in digital art,” “AI in graphic design,” “AI in photography.”

What’s the cause?

A) The synthesis agent does not detect gaps
B) The coordinator decomposed the task too narrowly (Correct)
C) The web search agent does not search thoroughly enough
D) The document analysis agent filters out non-visual sources

Gerekçe: Loglar, coordinator’ın “creative industries” konusunu yalnızca görsel alt başlıklara böldüğünü gösteriyor — müzik, edebiyat ve sinema tamamen atlanmış. Subagent’lar kendilerine verilen görevi doğru yürütmüş; sorun, ne atandığında. Multi-agent debug sorularında önce decomposition’a bak, sonra agent’lara.

Örnek 8 (Scenario: Multi-agent Research System)

Situation: A web-search subagent times out while researching a complex topic. You need to design how error information is passed back to the coordinator.

Which error propagation approach best enables intelligent recovery?

A) Return structured error context to the coordinator: failure type, query, partial results, and alternatives (Correct)
B) Implement automatic retries with exponential backoff inside the subagent, then return a generic “search unavailable” status
C) Catch the timeout inside the subagent and return an empty result set marked as success
D) Propagate the timeout exception to a top-level handler that terminates the whole workflow

Gerekçe: Structured error context (failure type + query + partial results + alternatives), coordinator’a akıllı karar için gereken her şeyi verir: değiştirilmiş sorguyla retry mi, alternatif yol mu, kısmi sonuçla devam mı. B bağlamı jenerik status arkasına gizler. C hatayı başarı olarak maskeler (sınavın en net “asla yapma” anti-pattern’i). D tüm workflow’u gereksiz öldürür.

Örnek 9 (Scenario: Multi-agent Research System)

Situation: The synthesis agent often needs to verify specific claims while merging results. Currently, when verification is needed, the synthesis agent hands control back to the coordinator, which calls the web-search agent and then re-runs synthesis with the new results. This adds 2–3 extra round trips per task and increases latency by 40%. Your assessment shows that 85% of these checks are simple fact checks (dates, names, statistics), while 15% require deeper investigation.

How do you reduce overhead while maintaining reliability?

A) Give the synthesis agent a limited verify_fact tool for simple checks, and continue routing complex verification through the coordinator (Correct)
B) Accumulate all verification needs into a batch and return them to the coordinator at the end
C) Give the synthesis agent full access to all web-search tools
D) Proactively cache additional context around each source

Gerekçe: Least privilege prensibinin ders kitabı uygulaması: synthesis agent %85’lik yaygın durum için tam ihtiyacı kadar yetki alır, %15’lik karmaşık doğrulama coordinator yolunda kalır. B bloklayan bağımlılıklar yaratır (sonraki synthesis adımları önceki doğrulanmış fact’lere bağlı olabilir). C sorumluluk ayrımını bozar. D, ihtiyacı güvenilir şekilde tahmin edemeyen spekülatif cache’e dayanır.

Örnek 10 (Scenario: Claude Code for CI)

Situation: A pipeline runs claude "Analyze this pull request for security issues", but hangs waiting for interactive input.

What is the correct approach?

A) Use the -p flag: claude -p "Analyze this pull request for security issues" (Correct)
B) Set CLAUDE_HEADLESS=true
C) Redirect stdin from /dev/null
D) Use --batch

Gerekçe: -p (veya --print), Claude Code’u non-interactive modda çalıştırmanın dokümante edilmiş yoludur: prompt’u işler, stdout’a yazar, çıkar. Diğer şıklar ya var olmayan özellikler ya da Unix workaround’larıdır. CI sorularında uydurma flag/env şıklarına dikkat — sınav var olmayan özellikleri çeldirici olarak kullanır.

Örnek 11 (Scenario: Claude Code for CI)

Situation: The team wants to reduce API cost for automated analysis. Claude currently serves two workflows in real time: (1) a blocking pre-merge check that must complete before developers can merge a PR, and (2) a tech-debt report generated overnight for morning review. A manager proposes moving both to the Message Batches API to save 50%.

How should you evaluate this proposal?

A) Use batch processing only for tech-debt reports; keep real-time calls for pre-merge checks (Correct)
B) Move both workflows to batch processing and poll for completion
C) Keep real-time calls for both to avoid ordering issues in batch results
D) Move both to batch processing with a fallback to real time if a batch takes too long

Gerekçe: Message Batches API %50 tasarruf sağlar ama işlem süresi 24 saate kadar çıkabilir ve garanti edilmiş latency SLA’sı yoktur. Bu, geliştiricilerin beklediği bloklayan pre-merge check için uygunsuz; gece çalışan tech-debt raporu için idealdir. Batch sorularının cevabı hep aynı eksende: latency’ye duyarlı mı, değil mi?

Örnek 12 (Scenario: Multi-file Code Review)

Situation: A pull request changes 14 files in an inventory tracking module. A single-pass review of all files produces inconsistent results: detailed comments for some files but superficial ones for others, missed obvious bugs, and contradictory feedback (a pattern is flagged as problematic in one file but approved in identical code in another file).

How should you restructure the review?

A) Split into focused passes: analyze each file individually for local issues, then run a separate integration pass for cross-file data flows (Correct)
B) Require developers to split large PRs into submissions of 3–4 files
C) Switch to a higher-tier model with a larger context window to review all 14 files in one pass
D) Run three independent full-PR review passes and report only issues found in at least two runs

Gerekçe: Odaklı geçişler kök nedeni — çok dosya tek geçişte işlenirken oluşan attention dilution — doğrudan çözer. Dosya başına analiz tutarlı derinlik sağlar; ayrı entegrasyon geçişi cross-file sorunları yakalar. B yükü geliştiriciye kaydırır. C bir yanılgıdır: daha büyük context window, attention kalitesini düzeltmez (sınavın favori çeldiricisi). D, tutarsız tespitler arasında konsensüs arayarak gerçek bug’ları bastırır.

4 Pratik Egzersiz

Sınav teorik görünse de soruların çoğu “bunu yapmış” birinin refleksini ölçer. Her egzersizi gerçekten kur ve çalıştır — her biri 1-2 saat sürer ve birden fazla domain’i kas hafızasına alır.

Egzersiz 1: Escalation mantıklı multi-tool agent

Hedef: Tool entegrasyonlu, yapısal hata yöneten ve escalation yapan bir agent loop tasarla.

Detaylı description’larla 3–4 MCP tool tanımla (tool seçimini test etmek için iki benzer tool ekle)
stop_reason kontrolü yapan agent loop yaz ("tool_use" / "end_turn")
Yapısal hata yanıtları ekle: errorCategory, isRetryable, açıklama
Eşik üstü işlemleri bloklayıp escalation’a yönlendiren bir interceptor hook yaz
Çok yönlü (multi-aspect) taleplerle test et

Domain’ler: D1 (Agent architecture), D2 (Tools/MCP), D5 (Context/reliability)

Egzersiz 2: Takım geliştirmesi için Claude Code konfigürasyonu

Hedef: CLAUDE.md, custom command, path-specific rule ve MCP server konfigürasyonu.

Evrensel standartları içeren proje seviyesi CLAUDE.md oluştur
Farklı kod alanları için YAML frontmatter’lı .claude/rules/ dosyaları yaz (paths: ["src/api/**/*"], paths: ["**/*.test.*"])
.claude/skills/ altında context: fork ve allowed-tools kullanan bir proje skill’i oluştur
.mcp.json içinde environment variable’lı bir MCP server + ~/.claude.json içinde kişisel override yapılandır
Farklı karmaşıklıktaki görevlerde planning mode vs direct execution’ı karşılaştır

Domain’ler: D3 (Claude Code config), D2 (Tools/MCP)

Egzersiz 3: Yapısal veri çıkarım pipeline’ı

Hedef: JSON schema, structured output için tool_use, validation/retry döngüsü, batch processing.

JSON schema’lı bir extraction tool tanımla (required/optional alanlar, “other” seçenekli enum’lar, nullable alanlar)
Validation döngüsü kur: hata durumunda belge + hatalı çıkarım + spesifik validation hatası ile retry et
Farklı yapıdaki belgeler için few-shot örnekleri ekle
Message Batches API ile 100 belgelik batch işle; hataları custom_id üzerinden eşleştir
İnsana yönlendirme ekle: alan seviyesi confidence skorları, belge türü analizi

Domain’ler: D4 (Prompt engineering), D5 (Context/reliability)

Egzersiz 4: Multi-agent araştırma pipeline’ı tasarımı ve debug’ı

Hedef: Subagent orkestrasyonu, context geçişi, hata yayılımı, kaynak takipli synthesis.

2+ subagent’lı bir coordinator kur (allowedTools içinde "Task", context prompt’larda açıkça geçirilir)
Tek yanıtta birden fazla Task çağrısıyla subagent’ları paralel çalıştır
Yapısal subagent çıktısı zorunlu kıl: claim, alıntı, kaynak URL, yayın tarihi
Subagent timeout’u simüle et: coordinator’a structured error context dön ve kısmi sonuçlarla devam et
Çelişen verilerle test et: her iki değeri atıflarıyla koru; doğrulanmış vs tartışmalı bulguları ayır

Domain’ler: D1 (Agent architecture), D2 (Tools/MCP), D5 (Context/reliability)

Teknoloji ve kavram kontrol listesi

Sınava girmeden önce her satırı “açıklayabiliyorum” diyene kadar işle:

Teknoloji	Bilmen gereken
Claude Agent SDK	AgentDefinition, agent loop, `stop_reason`, hook’lar (PostToolUse), Task ile subagent spawn, `allowedTools`
MCP	Server/tool/resource ayrımı, `isError`, tool description’lar, `.mcp.json`, environment variable’lar
Claude Code	CLAUDE.md hiyerarşisi, glob pattern’lı `.claude/rules/`, `.claude/commands/`, SKILL.md’li `.claude/skills/`, planning mode, `/compact`, `--resume`, `fork_session`
Claude Code CLI	Non-interactive için `-p` / `--print`, `--output-format json`, `--json-schema`
Claude API	JSON schema’lı `tool_use`, `tool_choice` (“auto”/“any”/forced), `stop_reason`, `max_tokens`, system prompt
Message Batches API	%50 tasarruf, 24 saate kadar pencere, `custom_id`, multi-turn tool calling YOK
JSON Schema	Required vs optional, nullable alanlar, enum + “other” + detay, strict mode
Built-in tool’lar	Read, Write, Edit, Bash, Grep, Glob — amaç ve seçim kriterleri
Few-shot prompting	Belirsiz durumlara hedefli örnekler, yeni pattern’lere genelleme
Prompt chaining	Odaklı geçişlere sıralı decomposition
Context window	Token bütçeleri, progressive summarization, “lost in the middle”, scratchpad dosyaları
Session yönetimi	Resume, `fork_session`, isimli session’lar, context izolasyonu
Confidence calibration	Alan seviyesi skorlama, etiketli set üzerinde kalibrasyon, stratified sampling

Kapsam dışı konular — bunlara çalışma

Aşağıdakiler sınavda çıkmaz; çalışma süreni bunlara harcama:

Fine-tuning veya custom model eğitimi
API authentication, faturalama, hesap yönetimi
Belirli dil/framework’lerde detaylı implementasyon (tool/schema konfigürasyonu için gereken dışında)
MCP server deploy/host etme (altyapı, networking, container orkestrasyon)
Claude’un iç mimarisi, eğitim süreci, model ağırlıkları
Constitutional AI, RLHF, safety training metodolojileri
Embedding modelleri veya vector database implementasyon detayları
Computer use (tarayıcı otomasyonu, masaüstü etkileşimi)
Vision (görüntü analizi)
Streaming API / server-sent events
Rate limiting, kota, detaylı API maliyet hesapları
OAuth, API key rotasyonu, authentication protokol detayları
Cloud sağlayıcıya özel konfigürasyonlar (AWS, GCP, Azure)
Performans benchmark’ları, model karşılaştırma metrikleri
Prompt caching implementasyon detayları (var olduğunu bilmek yeterli)
Token sayma algoritmaları, tokenization detayları

Sınav tuzağı: kapsam dışı bir teknoloji (vector DB, streaming, fine-tuning) çeldirici şık olarak sıkça görünür. “Bu kapsam dışı bir teknoloji” demek, çoğu zaman o şıkkı elemek için yeterlidir.

Senaryo 8 (Agentic AI Tools): rehberin boş bıraktığı alan için savunma planı

Rehber S8 içeriğini “content missing” olarak işaretliyor. Sınavda S8 gelirse şu mevcut bilgilerle çözülür:

tool_choice semantiği (auto / any / forced) — Ders 3.
Least privilege + allowedTools scoping — Ders 3.
Deterministic enforcement: hook / programmatic precondition > prompt talimatı — Ders 4 ve 11.
Tool seçim hatalarının kök neden analizi: description overlap → rename/netleştir, keyword routing anti-pattern’i — Ders 8.
Built-in vs MCP tool tercihi ve description güçlendirme — Ders 3.

S8 soruları büyük olasılıkla bu beş kalıbın senaryolu halidir.

Hazırlık önerileri (resmî rehberden)

Claude Agent SDK ile bir agent kur — tool calling, hata yönetimi ve session yönetimi içeren tam bir agent loop. Subagent’ları ve açık context geçişini pratiğe dök.
Gerçek bir projede Claude Code’u yapılandır — CLAUDE.md hiyerarşisi, .claude/rules/ path kuralları, context: fork + allowed-tools skill’leri, MCP entegrasyonu.
MCP tool’ları tasarla ve test et — benzer tool’ları ayrıştıran description’lar yaz, kategorili + retry flag’li yapısal hatalar dön, belirsiz taleplere karşı test et.
Veri çıkarım pipeline’ı kur — JSON schema’lı tool_use, validation/retry döngüleri, optional/nullable alanlar, Batches API.
Prompt engineering pratiği yap — belirsiz senaryolara few-shot, açık review kriterleri, büyük review’lar için multi-pass mimari.
Context yönetim pattern’lerini çalış — uzun çıktılardan fact extraction, scratchpad dosyaları, keşfi subagent’lara delege etme.
Escalation ve human-in-the-loop’u anla — ne zaman escalate edilir (policy gap, açık kullanıcı talebi, ilerleme yokluğu) ve confidence tabanlı yönlendirme.
Gerçek sınavdan önce practice exam çöz — aynı senaryolar ve format kullanılıyor. Ders 11’deki 76 soruluk simülasyon tam bunun için.
Practical test’i (repo: practical_test_en.html, 60 soru) en az bir kez baştan sona çöz — format birebir sınav simülatörü.

Sınav günü son kontrol

60 soru / 90 dakika / geçme notu 720 (≈%72). Soru başına 1.5 dakika.
Her soruda önce kök nedeni belirle, sonra şıkları “enforcement mi rehberlik mi”, “latency’ye duyarlı mı”, “least privilege’a uygun mu” süzgeçlerinden geçir.
“Hatayı başarı olarak maskele”, “self-rated confidence”, “daha büyük context window her şeyi çözer”, “var olmayan flag/env” şıkları her zaman yanlıştır.
Emin olmadığın soruyu işaretle, geç, sona dön — bir soruda 3+ dakika harcama.

Özet

12 açıklamalı örnek soru, sınavın karar prensiplerini izole eder: deterministik garanti > prompt, tool description birincil seçim mekanizması, planning mode = büyük/belirsiz işler, batch = latency’ye duyarsız işler, multi-pass = attention dilution çözümü, least privilege, structured error context.
4 pratik egzersiz 5 domain’in tamamını kapsar; her birini gerçekten kurmak sınav reflekslerini geliştirir.
Kapsam dışı listesi hem çalışma planını sadeleştirir hem çeldirici şıkları elemeyi kolaylaştırır.
Son adım: Ders 11’deki 76 soruluk tam simülasyonu süre tutarak çöz; %80+ isabet gerçek sınav için yeterli sinyaldir.