Lo que me funcionó para el examen Claude Certified Architect – Foundations (CCA-F), en julio de 2026. Si te ayuda a llegar más tranquilo al examen, ya valió la pena.
Antes de estudiar, leí testimonios en Reddit de quienes ya habían hecho el examen para calibrar el nivel de exigencia y descubrir buenas plataformas. Después hice un simulacro corto (28 preguntas) solo para ubicarme: dónde estaba y qué profundidad se exigía.
El examen tiene una parte agéntica, que lo permea todo, y una parte específica de Claude (CLI, biblioteca, configuraciones). Yo tenía buena base en la parte agéntica — lo que necesitaba era refinamiento técnico y velocidad. La configuración era mi punto débil con diferencia, y ahí sí necesitaba la teoría de verdad.
Muchas cosas se pueden responder con lo que harías en el trabajo: la opción más confiable y que da menos trabajo. Pero Claude tiene una estructura propia, y me equivoqué varias veces con total confianza. Ejemplo clásico: un workflow gigante reventando el límite de budget — la respuesta no es cambiar de modelo ni tocar ese límite. En el examen, la respuesta es escalar a un humano.
Tomé los simulacros y anoté, en cada pregunta fallada, lo que yo creía que era, lo que entendí mal y lo que no sabía. Esa lista se convirtió en mi plan de estudios vivo: lo actualizaba siempre para atacar los talones de Aquiles. De configuración hice tantos ejercicios que llegué a memorizarlos, así que pasé a los demás temas.
Solo después de dominar el formato de las preguntas fui a la teoría pura. Puede parecer lo contrario de lo esperado, pero, para mí, comprender primero cómo pregunta la banca me permitió responder más rápido lo que ya sabía y que sobrara tiempo para la revisión al final del examen, matando las preguntas más difíciles. Otra razón para dejar la teoría para el final fue justamente refinar el contenido para responder esas preguntas.
Junté todas las fuentes que consideré importantes y las fui desglosando en notas dentro de una llm-wiki. Casi no hice cuadernos a mano — lo único que anoté en una pizarra fue grep vs glob.
.claude/).Aquí la nota del simulacro casi no subía — fui de 788 a 798, por ejemplo. Y está bien: el objetivo de esta fase es coger ritmo, cansarse menos leyendo y, sobre todo, estudiar lo que iba fallando. En cada simulacro revisaba pregunta por pregunta, anotaba el razonamiento y actualizaba el foco de los estudios. Para mí, la revisión forma parte de esta fase: es estudiar después de la práctica, atacando primero los temas donde más fallaba.
Cuando ya terminaba rápido y "de un vistazo lo sabía", lo que quedaba eran las preguntas difíciles, decididas por teoría pura — la crème de la crème. Ahí cambié el chip para estudiar la teoría a fondo y refinar esas preguntas. No siempre daba tiempo a leerlo todo, y está bien: priorizaba los temas más difíciles.
La revisión solo funciona si es específica. Un ejemplo real de mi cuaderno: "q42 — me quedé con la duda. Creí que necesitaría todo tipo de análisis, por eso el free text. Lección: evitar free text cuando necesito consistencia. Transformar la tool que recibe free text en 3 tools de análisis específicas, con outputs bien definidos." Esa lista de errores + motivos era lo que alimentaba el siguiente ciclo de estudio.
allowTools: Agent (antes Task).Task, alias de Agent.Muchas veces lo que parece más correcto es over-engineering. Simplifica hasta encontrar el nivel correcto de la corrección — hazlo como lo harías en el trabajo: la solución más confiable y que da menos trabajo. Y lee el escenario completo solo cuando te trabes y necesites más contexto.
Cuando te atasques entre alternativas, la apuesta suele apuntar a: few-shot, mejorar la descripción de la tool o usar un schema JSON en la respuesta. Y, en Claude Code, la ejecución suele fallar por falta de planificación.
Alternativas que pueden sonar plausibles pero casi nunca son la respuesta correcta:
| Tachar | Por qué |
|---|---|
| Reprocesar todo / volver a ejecutar | No ataca la causa y sale caro. |
| Quitar o aumentar el límite de tokens | El problema vuelve. Divide el doc para vencer. |
| Pedirle a Claude que "se esfuerce más" | No es así como se resuelve. |
| Cambiar de modelo (más caro o más barato) | Puede alterar la calidad. |
| Subir/bajar la temperatura | Curiosamente, nunca es la respuesta. |
| Llamar varias veces y sacar la media | Apaño caro e inestable. |
| Dar más de 5 tools a un agente | El exceso de opciones degrada la elección. |
| Mandar todo a revisión humana | Escala solo lo que realmente lo necesita. |
| Bloquear todo el pipeline ante un error | En su lugar, propaga el error. |
| Apilar un modelo nuevo en el pipeline | Validación/clasificación de más rara vez ayuda. |
| Devolver vacío o fallar en silencio | El error silencioso es una trampa. |
| Retry automático dentro de la tool | Quien decide volver a llamar es el agente. |
Ejecutar /compact para contexto degradado | No es la cura para la degradación. |
| Nivel | Alcance | Cuándo se lee | Ruta |
|---|---|---|---|
| Sistema | Tu máquina | Siempre | ~/.claude/ |
| Proyecto | Quien clone el repo | Al abrir el proyecto | .claude/ |
| Directorio | Instrucciones de la carpeta | Al explorar la carpeta | src/CLAUDE.local.md |
| Rules | Instrucciones con path en el YAML frontmatter | Match en el glob (*.md, tests/) | .claude/ |
| Skills | Instrucciones especiales (tienen fork de contexto) | Si es relevante en el chat | .claude/skills/analysis/SKILL.md |
| Comandos | Alias de skill | Si es relevante en el chat | .claude/commands/analysis.md |
| Dónde | ¿Versionado? | Ruta | Para qué |
|---|---|---|---|
| Personal | No versionado | ~/.claude/CLAUDE.md | Reglas globales para todos tus proyectos |
| Equipo | Versionado | CLAUDE.md y .claude/ | El Claude del equipo |
| Personal | No versionado | CLAUDE.local.md | Preferencias personales para el directorio |
Read, Grep, Glob, Write, EditSi tuviera que resumirlo: entender el patrón de la banca me hizo más rápida, y esa velocidad me dio unos 30 minutos de revisión al final del examen. Fue revisando con calma las preguntas más difíciles como aprobé tranquila.
Solo con teoría, no habría tenido tiempo en el examen ni para revisar ni para leer con calma. Solo con preguntas, no habría podido con las más difíciles y correría más riesgo de aprobar raspando — o de no aprobar. Por eso primero creé ese tiempo de sobra y, después, refiné el contenido para usarlo bien. En el examen revisé más de 15 preguntas que me parecieron súper difíciles y llegué a cambiar algunas respuestas marcadas.
Nada de esto es una regla — es solo lo que encajó conmigo. Si adaptas una o dos de estas ideas y llegas más confiado el día del examen, el objetivo de este post está cumplido. Buen examen, y ojalá te salga bien. 💜