Los 6 Escenarios del Examen
Los 6 Escenarios del Examen
Anterior: Reliability y Escalación · Índice · Siguiente: Simulacro
Formato del examen
El examen presenta 4 de estos 6 escenarios por intento. Cada escenario tiene un contexto de negocio y preguntas multiple-choice scenario-based. Los escenarios cubren múltiples dominios simultáneamente.
Escenario 1: Customer Support Resolution Agent
Dominios: D1 (Agentic Architecture) + D2 (Tool Design & MCP) + D5 (Reliability)
Contexto
Un agente automatizado resuelve tickets de soporte al cliente. Usa tools para consultar bases de datos, procesar reembolsos, y escalar a humanos cuando es necesario.
Conceptos que se testean
- MCP tools: Cómo diseñar tools que el agente usa para consultar customer data, procesar acciones
- Hooks: Pre-tool hooks para logging de acciones sensibles (reembolsos)
- Escalación: Cuándo y cómo escalar a humanos con structured summaries
- Enforcement: Guardrails que impiden acciones fuera de policy (reembolso > threshold)
- Agentic loop: Cómo el agente itera entre tool calls hasta resolver o escalar
Trampas comunes
- Confundir cuándo usar hooks vs guardrails en el system prompt
- Creer que self-review es suficiente para validar acciones de alto impacto
- Olvidar que la escalación requiere structured summary, no raw transcript
- Pensar que retry es apropiado para policy violations (es fail-fast)
Preguntas ejemplo
P1: El agente debe procesar un reembolso de $800 pero el policy limit es $500. ¿Qué debería hacer?
- A) Procesar el reembolso igualmente (INCORRECTO — viola policy)
- B) Dividir en dos reembolsos de $400 (INCORRECTO — evasión de policy)
- C) Escalar a humano con summary del caso y recomendación (CORRECTO)
- D) Pedir al cliente que acepte $500 (INCORRECTO — no autorizado)
P2: ¿Qué tipo de hook es apropiado para logear acciones de reembolso?
- A) PostToolUse para verificar que la acción se completó (INCORRECTO — es post, no pre)
- B) PreToolUse que logea el intent antes de ejecutar (CORRECTO)
- C) Stop hook que bloquea la acción (INCORRECTO — logear no es bloquear)
- D) System prompt instruction (INCORRECTO — no es un hook)
Escenario 2: Code Generation with Claude Code
Dominios: D3 (Claude Code Config) + D5 (Reliability)
Contexto
Un equipo de desarrollo configura Claude Code para su organización. Involucra CLAUDE.md, plan mode, session management, y permisos.
Conceptos que se testean
- CLAUDE.md: Jerarquía de settings (global, proyecto, usuario), qué va dónde
- Plan mode: Cuándo usar plan mode vs implementación directa
- Session management: Cuándo empezar nueva sesión, cómo hacer handoffs
- Permisos y sandbox: Qué puede hacer Claude Code con cada nivel de permisos
Trampas comunes
- No saber la precedencia de CLAUDE.md (proyecto > usuario > global)
- Confundir plan mode con ask mode
- Creer que Claude Code carga todo el repo en contexto (no lo hace)
- Pensar que
.claude/settings.jsonyCLAUDE.mdtienen el mismo propósito
Preguntas ejemplo
P1: Un developer tiene CLAUDE.md global que dice “use tabs” y el proyecto tiene CLAUDE.md que dice “use spaces”. ¿Cuál se aplica?
- A) Global (INCORRECTO)
- B) El más reciente (INCORRECTO)
- C) El del proyecto (CORRECTO — proyecto overrides global)
- D) Depende del archivo (INCORRECTO)
P2: Un developer quiere que Claude Code planifique una refactorización grande antes de implementar. ¿Qué debe hacer?
- A) Escribir el plan en CLAUDE.md (INCORRECTO)
- B) Usar plan mode para que Claude Code proponga un plan antes de codear (CORRECTO)
- C) Pedir a Claude que no toque archivos (INCORRECTO)
- D) Usar ask mode (INCORRECTO — ask mode es para preguntas, no planificación)
Escenario 3: Multi-Agent Research System
Dominios: D1 (Agentic Architecture) + D2 (Tool Design) + D5 (Reliability)
Contexto
Un sistema multi-agente donde un coordinator orquesta subagentes especializados para investigación, análisis y síntesis de información.
Conceptos que se testean
- Coordinator pattern: Cómo el coordinator distribuye trabajo y recopila resultados
- Subagent spawning: Cuándo crear subagentes vs manejar en el mismo agente
- Tool distribution: Qué tools tiene cada subagente vs el coordinator
- Context passing: Cómo pasar información entre agentes (archivos, no contexto compartido)
- Failure handling: Qué pasa cuando un subagente falla
Trampas comunes
- Dar todas las tools al coordinator (debe delegar)
- Compartir contexto entre subagentes directamente (usar archivos)
- No tener fallback cuando un subagente falla
- Pensar que el coordinator debe hacer el trabajo detallado
Preguntas ejemplo
P1: El coordinator necesita que 3 subagentes investiguen topics diferentes. ¿Cómo debe pasar los resultados entre ellos?
- A) Cada subagente accede al contexto del anterior (INCORRECTO)
- B) El coordinator pasa el transcript completo al siguiente (INCORRECTO)
- C) Cada subagente escribe resultados a archivos, el coordinator los lee y distribuye (CORRECTO)
- D) Todos los subagentes comparten un context window (INCORRECTO)
Escenario 4: Developer Productivity with Claude
Dominios: D1 (Agentic Architecture) + D2 (Tool Design) + D3 (Claude Code Config)
Contexto
Integración de Claude en el workflow de desarrollo diario: built-in tools, MCP para herramientas internas, y Agent SDK para automatización.
Conceptos que se testean
- Built-in tools: Read, Edit, Bash, Glob, Grep — cuándo usar cada uno
- MCP integration: Conectar herramientas internas (JIRA, Slack, DB) via MCP
- Agent SDK: Automatizar workflows con el SDK programáticamente
- Tool design: Schemas claros, error handling, descripciones que guíen selección
Trampas comunes
- No saber qué tools son built-in vs requieren MCP
- Diseñar tools con parámetros ambiguos
- No incluir error responses en el schema de tools
- Confundir el Agent SDK con la API de mensajes
Preguntas ejemplo
P1: Un equipo quiere que Claude Code consulte tickets de JIRA durante code review. ¿Cuál es la forma correcta?
- A) Incluir el ticket en el prompt manualmente (INCORRECTO — no escala)
- B) Configurar un MCP server que exponga JIRA como tool (CORRECTO)
- C) Usar la built-in Bash tool para curl a la API de JIRA (INCORRECTO — no es mantenible ni seguro)
- D) Copiar el contenido del ticket a CLAUDE.md (INCORRECTO)
Escenario 5: Claude Code for CI/CD
Dominios: D3 (Claude Code Config) + D4 (Prompt Engineering)
Contexto
Usar Claude Code en pipelines de CI/CD para code review automatizado, generación de tests, y quality gates.
Conceptos que se testean
- -p flag: Ejecutar Claude Code en modo non-interactive para CI/CD
- Structured output: Producir resultados parseables para quality gates
- Review criteria: Definir qué buscar y qué ignorar (false positives)
- Batch processing: Cuándo batch vs real-time en CI/CD
Trampas comunes
- Usar batch API para pre-merge checks (no tiene SLA de latency)
- No definir criterios explícitos → muchos falsos positivos
- Olvidar el flag
-ppara non-interactive mode - No parsear el output para integrarlo con CI tools
Preguntas ejemplo
P1: Tu CI pipeline usa Claude Code para review pero developers ignoran los resultados porque hay muchos falsos positivos en la categoría “naming conventions”. ¿Mejor acción?
- A) Aumentar el timeout del CI (INCORRECTO — no relacionado)
- B) Deshabilitar temporalmente la categoría y refinar criterios (CORRECTO)
- C) Cambiar a un modelo más grande (INCORRECTO — no resuelve FP)
- D) Agregar “be more careful” al prompt (INCORRECTO — vago)
P2: Necesitas integrar Claude Code en GitHub Actions para review automático. ¿Cómo lo ejecutas?
- A)
claude code review.ts(INCORRECTO — no es un comando válido) - B)
claude -p "review the PR changes"con output parseado (CORRECTO) - C) Iniciar sesión interactiva en el runner (INCORRECTO — CI no es interactivo)
- D) Usar la web interface (INCORRECTO — no es CI/CD)
Escenario 6: Structured Data Extraction
Dominios: D4 (Prompt Engineering) + D5 (Reliability)
Contexto
Pipeline de extracción de datos estructurados de documentos variados (facturas, contratos, reportes). Involucra JSON schemas, tool_use, validación y batch processing.
Conceptos que se testean
- JSON schemas: Diseño de schemas con required vs nullable fields
- tool_use: Usar tool_use como mecanismo de structured output
- Validation loops: Retry con feedback de errores de validación
- Batch processing: Procesar grandes volúmenes con Batches API
- Few-shot: Reducir alucinaciones en extracción con examples
Trampas comunes
- Hacer todos los campos required (causa alucinaciones en campos faltantes)
- No incluir self-correction fields (calculated vs stated)
- Pensar que strict schemas previenen errores semánticos
- No probar el prompt en sample set antes del batch
Preguntas ejemplo
P1: Tu extracción produce JSON válido pero el campo “total” no coincide con la suma de line items. ¿Cuál es la causa?
- A) El schema es incorrecto (INCORRECTO — schema valida estructura, no semántica)
- B) Error semántico que schemas no pueden prevenir (CORRECTO)
- C) Claude no soporta aritmética (INCORRECTO)
- D) Falta tool_choice forced (INCORRECTO — no relacionado)
P2: Procesarás 10,000 facturas durante la noche. ¿Cuál es el approach óptimo?
- A) Real-time API con paralelismo (INCORRECTO — más caro)
- B) Probar prompt en sample, luego Batches API (CORRECTO)
- C) Batches API directamente sin testing previo (INCORRECTO — arriesga re-procesamiento)
- D) Claude Code con -p en un loop (INCORRECTO — no es la herramienta correcta)
Mapa de dominios por escenario
| Escenario | D1 | D2 | D3 | D4 | D5 |
|---|---|---|---|---|---|
| 1. Customer Support | X | X | X | ||
| 2. Code Generation | X | X | |||
| 3. Multi-Agent Research | X | X | X | ||
| 4. Developer Productivity | X | X | X | ||
| 5. CI/CD | X | X | |||
| 6. Data Extraction | X | X |
Nota: El examen presenta 4 de 6 escenarios. Debes estar preparado para todos porque no sabes cuáles te tocarán.
Resumen de preparación
- Practica cada escenario mentalmente: lee el contexto, identifica los dominios, anticipa preguntas
- Enfócate en anti-patterns — el examen pregunta frecuentemente qué NO hacer
- Conecta dominios — cada escenario toca 2-3 dominios, practica la intersección
- Lee las opciones completas — las respuestas incorrectas suelen ser “casi correctas”
- Busca la opción específica — la correcta es casi siempre la más específica y accionable
Anterior: Reliability y Escalación · Índice · Siguiente: Simulacro