22 Preguntas de Práctica de Configuración y flujos de trabajo de Claude Code con Respuestas

1. 1. Las convenciones de código compartidas de un equipo están en ~/.claude/CLAUDE.md, en la máquina del líder técnico. Las personas nuevas clonan el repositorio y Claude Code ignora por completo esas convenciones. ¿Cuál es la corrección adecuada?

   • A.Mover las convenciones a ./CLAUDE.md en la raíz del repositorio y versionarlo, para que todo clon cargue ese archivo.✓ Respuesta
   • B.Dejar el archivo en ~/.claude/CLAUDE.md y pedir a cada persona nueva que copie la versión del líder en su directorio.
   • C.Pegar las convenciones en un comando de barra del proyecto que los revisores ejecuten a mano antes de aprobar cada PR.
   • D.Añadir las convenciones a la plantilla de prompt del líder y pedir que se pegue ese texto al inicio de cada sesión.

   Los archivos de memoria tienen ámbitos: uno de nivel usuario bajo ~/.claude/ es personal y aplica a todos los proyectos de esa persona, mientras que ./CLAUDE.md (o ./.claude/CLAUDE.md) viaja con el repositorio a través del control de versiones. Una convención de equipo puesta en el ámbito de usuario nunca llega a un compañero, así que hay que moverla al ámbito de proyecto y versionarla.

   Ref. QB-C69FGJFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 3: Claude Code Configuration; Claude Code memory docs (user vs project memory scope)Reportar un problema con esta pregunta

2. 2. Un equipo decide qué va en el CLAUDE.md de proyecto y qué queda en cada prompt individual. ¿Qué reparto corresponde al propósito del archivo?

   • A.El texto del ticket actual y la lista de archivos a tocar van en el archivo; las convenciones del equipo, en cada prompt.
   • B.Los comandos de build, las notas de arquitectura y las prohibiciones van en el archivo; el detalle de la tarea va en el prompt.✓ Respuesta
   • C.Solo una descripción de una línea del proyecto va en el archivo; los comandos y convenciones van en una wiki del equipo fijada.
   • D.Lo que el modelo equivocó dos veces va en el archivo; los comandos, convenciones y prohibiciones van en cada prompt nuevo.

   El archivo de instrucciones del proyecto se carga al inicio de cada sesión, así que debe contener lo que es cierto para todas las tareas: cómo compilar y probar, cómo está organizado el código, cómo nombrar cosas y qué nunca debe hacerse. Lo específico de un trabajo concreto va mejor en el prompt, donde no queda como instrucción permanente para tareas ajenas.

   Ref. QB-UN3AWHFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 3: project memory content vs per-task prompt contentReportar un problema con esta pregunta

3. 3. Una convención solo aplica a archivos de prueba llamados *.test.tsx, que están junto a los componentes que prueban en muchos directorios distintos. ¿Cómo debería configurarla el equipo para que el agente la cargue solo en ese trabajo?

   • A.Ponerla en un archivo bajo .claude/rules/ y declarar el glob de los tests en el campo paths del frontmatter para cargarla ahí.✓ Respuesta
   • B.Poner un CLAUDE.md en cada directorio que contenga archivos de prueba, para que la convención se cargue al leer un archivo allí.
   • C.Ponerla en el CLAUDE.md raíz, abriendo con una línea que le indique aplicarla únicamente cuando esté editando un archivo de prueba.
   • D.Ponerla en una skill y pedir al equipo que la invoque por su nombre cada vez que solicite un cambio en un archivo de prueba.

   Los archivos de reglas con ámbito de ruta llevan en su frontmatter una lista paths de patrones glob y solo se cargan cuando Claude trabaja con archivos que coinciden, que es justo el caso cuando esos archivos están repartidos por el árbol y no reunidos en una carpeta. Un CLAUDE.md por directorio sirve solo si la convención se limita de verdad a un subárbol, y una salvedad en prosa en el archivo raíz sigue gastando contexto en cada sesión.

   Ref. QB-B6W4BHFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 3: .claude/rules/ path-scoped rules with paths frontmatterReportar un problema con esta pregunta

4. 4. El CLAUDE.md de un proyecto se ha vuelto largo, así que alguien propone dividir secciones en archivos aparte traídos con @import. ¿Qué se consigue realmente con eso?

   • A.Aplaza cada archivo importado hasta que Claude toca una ruta que coincide, dejando en la sesión solo lo relevante.
   • B.Mantiene los estándares modulares y fáciles de mantener, pero los imports se cargan igual al inicio y el contexto no baja.✓ Respuesta
   • C.Permite que cada persona sobrescriba localmente un archivo importado, sin que el archivo del proyecto deje de mandar.
   • D.Comprime al inicio las secciones importadas en un resumen, de modo que los estándares siguen disponibles con menos contexto.

   @import es un mecanismo de organización: los archivos referenciados se resuelven y cargan junto con el resto del archivo de memoria al iniciar la sesión, así que el costo en tokens es el mismo que si el texto estuviera en línea. La carga condicional por ruta la ofrecen los archivos de reglas con frontmatter paths, no @import.

   Ref. QB-XN5AENFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 3; Claude Code memory docs (@import resolution at launch)Reportar un problema con esta pregunta

5. 5. Un equipo quiere un comando /release-checks que todos obtengan automáticamente al clonar el repositorio. ¿Dónde debe definirse?

   • A.En un archivo markdown dentro de .claude/commands/ del repositorio, versionado para que cada clon tenga el comando.✓ Respuesta
   • B.En un archivo markdown dentro de ~/.claude/commands/ de cada equipo, que cada persona copia tras clonar el repo.
   • C.En un arreglo commands dentro de .claude/config.json del repositorio, con el nombre y el prompt de cada comando.
   • D.En una skill bajo .claude/skills/ cuyo frontmatter registra un nombre para que aparezca en el menú de barra.

   Los comandos de barra son archivos markdown descubiertos por directorio: .claude/commands/ del repositorio tiene ámbito de proyecto y control de versiones, así que basta con traer el repo, mientras que ~/.claude/commands/ es personal de una máquina. No existe un arreglo commands en .claude/config.json, y una skill se carga por relevancia en vez de registrarse como entrada de barra.

   Ref. QB-E6Y4UMFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 3: project vs personal slash command directoriesReportar un problema con esta pregunta

6. 6. ¿Qué contenedor conviene para un procedimiento de migración de varios pasos que el agente debería adoptar por su cuenta cuando el trabajo toca el módulo de pagos, sin que nadie lo nombre?

   • A.Un comando de barra, porque escribir su nombre es la manera más rápida de traer el procedimiento al chat.
   • B.Una skill, porque su descripción permite que el modelo cargue el procedimiento cuando el trabajo encaja.✓ Respuesta
   • C.Un hook, porque el arnés puede inyectar el procedimiento de forma determinista antes de cada llamada.
   • D.Un subagente, porque un contexto aparte es el único sitio donde cabe guardar un procedimiento largo.

   Una skill son instrucciones empaquetadas más una descripción que el modelo contrasta con el trabajo en curso, de modo que se carga bajo demanda sin invocación explícita. Un comando de barra es un atajo que alguien debe escribir, un subagente es un contexto aparte con su propio encargo, y un hook es automatización del arnés ligada a eventos, no al tema del trabajo.

   Ref. QB-WNSX8MFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 3: skills vs slash commands vs subagentsReportar un problema con esta pregunta

7. 7. Una skill ejecuta una auditoría de dependencias cuya salida son miles de líneas que ya no le sirven a nadie una vez hay resumen. ¿Qué ajuste del frontmatter lo resuelve?

   • A.context: fork, que ejecuta la skill en un subagente aislado y devuelve solo su resultado a la conversación.✓ Respuesta
   • B.argument-hint, que pide de entrada el alcance de la auditoría para que la skill revise menos paquetes.
   • C.model, que dirige la skill a un modelo más pequeño cuyas respuestas son más cortas en salidas masivas.
   • D.allowed-tools, que limita las herramientas que la skill puede llamar y así reduce las líneas de salida.

   Ejecutar una skill con context: fork le da su propio contexto aislado, de modo que la salida intermedia extensa se consume allí y al hilo principal solo vuelve el resultado. Esa es la razón general para usar un subagente: el trabajo cuyo material bruto nadie necesita después no debe ocupar el contexto del que depende el resto de la sesión.

   Ref. QB-D6MSNKFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 3; Claude Code skills docs (frontmatter: context, allowed-tools, argument-hint)Reportar un problema con esta pregunta

8. 8. Un job de CI ejecuta `claude "review this diff"` como paso de build y se queda colgado hasta que el timeout lo mata. ¿Qué lo arregla?

   • A.Enviar el diff por stdin, que la CLI interpreta como señal para ejecutarse una vez y salir sin preguntar.
   • B.Ejecutarlo con -p (--print) para una corrida no interactiva y --output-format json para los hallazgos.✓ Respuesta
   • C.Definir CLAUDE_HEADLESS=1 en el entorno del job para que la CLI omita el prompt interactivo y emita texto.
   • D.Añadir la bandera --batch para que la CLI encole la petición y salga, y consultar el resultado después.

   Una invocación sin banderas abre una sesión interactiva, que nunca termina en un entorno sin terminal; -p (--print) es la bandera documentada para una corrida única no interactiva que imprime y sale. Combinarla con --output-format json hace el resultado parseable por máquina para publicar hallazgos como comentarios de PR, mientras que CLAUDE_HEADLESS y --batch no son controles reales.

   Ref. QB-RNZ9DEFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 3: headless/CI invocation (-p/--print, --output-format json)Reportar un problema con esta pregunta

9. 9. Alguien está escribiendo el bucle que conduce a un agente a través de llamadas a herramientas. ¿Qué flujo de control es correcto?

   • A.Continuar un máximo fijo de diez iteraciones, añadiendo cada tool_result, y devolver lo acumulado.
   • B.Continuar mientras stop_reason sea tool_use, añadiendo cada tool_result, y parar cuando sea end_turn.✓ Respuesta
   • C.Continuar mientras la respuesta traiga texto, añadiendo cada tool_result, y parar si solo llega texto.
   • D.Continuar hasta que el texto del asistente diga que la tarea terminó, añadiendo cada tool_result.

   stop_reason es la señal estructurada que la API da sobre por qué terminó el turno, así que la condición del bucle debe apoyarse en ella: tool_use significa que el modelo espera resultados y end_turn que ya terminó. Interpretar frases de cierre en lenguaje natural, contar hasta un tope fijo o mirar si hay bloques de texto sustituyen una señal determinista por una probabilística y hacen que el bucle pare antes o después de tiempo.

   Ref. QB-86U4TDFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 1: agentic loop control via stop_reasonReportar un problema con esta pregunta

10. 10. Un repositorio exige ejecutar un formateador antes de cada commit. La instrucción está en CLAUDE.md, pero el agente a veces hace commit sin ella. ¿Qué hace fiable ese paso?

    • A.Mover el formateo a una skill y exigir que el modelo la cargue antes de cada commit, como parte del flujo.
    • B.Denegar por completo la herramienta de commit y pedir que una persona lo haga, evitando commits sin formato.
    • C.Configurar un hook que el arnés ejecuta en la llamada correspondiente, ya que se dispara sin decisión del modelo.✓ Respuesta
    • D.Reformular la regla con palabras más firmes al inicio del CLAUDE.md, porque lo que va primero se cumple mucho mejor.

    Un hook es automatización que el arnés ejecuta ante un evento coincidente, no una acción que el modelo elige, así que corre siempre y no depende de que se sigan instrucciones. Las instrucciones en el prompt, por enfáticas o bien ubicadas que estén, tienen una tasa de fallo distinta de cero, y por eso lo crítico para el negocio se impone de forma estructural.

    Ref. QB-6TAPMEFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 1: hooks as deterministic enforcement vs prompt instructionReportar un problema con esta pregunta

11. 11. Un equipo redacta reglas de permisos para su agente. ¿Cuál es la diferencia entre una regla allow y una regla deny?

    • A.Una regla deny bloquea la llamada aunque una regla allow la cubra; la allow solo evita la confirmación previa.✓ Respuesta
    • B.Ambas son señales orientativas que el modelo pondera, así que una deny redactada con firmeza pesa más.
    • C.Una regla allow bloquea todo lo que no enumera, y una deny solo avisa mientras la llamada sigue su curso.
    • D.Una regla deny vale solo para la sesión actual, y una allow persiste una vez que se aprobó por primera vez.

    Las reglas de permisos las evalúa el arnés, no el modelo, y una coincidencia deny gana sobre una allow, y por eso deny es la afirmación más fuerte: elimina una capacidad en vez de facilitar su uso. Una regla allow no concede nada que el agente no pudiera intentar de todos modos; solo preaprueba la llamada para que no se pida confirmación.

    Ref. QB-PAGU7FFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 3: permission rules; Claude Code permissions (deny takes precedence over allow)Reportar un problema con esta pregunta

12. 12. Antes de adoptar una herramienta de codificación agéntica, un equipo debate concederle ejecución de shell sin restricciones. ¿Por qué es una categoría de riesgo distinta al permiso de editar archivos?

    • A.La ejecución de shell sin restricciones sube sobre todo el costo, porque el agente lanza muchos más comandos en cada tarea.
    • B.La ejecución de shell sin restricciones debilita la elección de herramientas: la shell compite con las de archivos.
    • C.La ejecución de shell sin restricciones abarca los demás permisos: alcanza archivos y hosts que ninguna regla listó.✓ Respuesta
    • D.La ejecución de shell sin restricciones frena la revisión, porque hay que leer las trazas de comandos además del diff final.

    Una shell es una capacidad de superconjunto: lo que los permisos de herramientas acotan con cuidado, un solo comando puede hacerlo igual, incluido leer archivos fuera del proyecto y abrir conexiones de red. Por eso la adopción exige responder qué puede ejecutar el agente, qué puede alcanzar en la red, qué debe confirmar una persona y qué queda registrado, y por eso el acceso a shell se acota a comandos concretos.

    Ref. QB-5TXBFDFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 3: permissions and least-privilege scoping of executionReportar un problema con esta pregunta

13. 13. Un coordinador delega parte de una tarea en un subagente y este pide de inmediato información que el coordinador ya había establecido varios turnos antes. ¿Qué lo explica?

    • A.El subagente lee el historial de forma perezosa, así que lo no escrito aún en CLAUDE.md falta en su primer turno.
    • B.El subagente arranca con contexto aislado y no hereda el historial del coordinador, así que los datos van en su prompt.✓ Respuesta
    • C.El subagente comparte memoria solo con invocaciones previas, así que los datos llegan una delegación más tarde.
    • D.El subagente hereda el historial pero con ventana menor, por lo que se descarta primero la parte más antigua.

    Los subagentes corren en su propio contexto y ni heredan la conversación del coordinador ni comparten memoria entre invocaciones, que es justo lo que los hace útiles para aislar trabajo extenso. La consecuencia de diseño es que cada dato que el subagente necesita debe declararse explícitamente en el prompt de delegación.

    Ref. QB-NA5H2EFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 1: subagent context isolation and explicit context passingReportar un problema con esta pregunta

14. 14. Un equipo quiere que todos se conecten al mismo servidor MCP de Jira sin que el token de API acabe en el repositorio. ¿Qué configuración logra ambas cosas?

    • A.Pedir a cada persona que agregue el servidor a mano en su ~/.claude.json, dejando la configuración fuera del repo.
    • B.Versionar .mcp.json en la raíz del proyecto y escribir el token como ${JIRA_TOKEN}, que se expande del entorno.✓ Respuesta
    • C.Versionar un script de instalación que escriba el token en ~/.claude.json en la primera ejecución, para todos.
    • D.Versionar .mcp.json en la raíz del proyecto con el token en línea y luego añadir ese archivo a .gitignore.

    El .mcp.json de proyecto es el lugar compartido y versionado para declarar un servidor —su transporte y sus datos de arranque—, así que un clon obtiene el mismo utillaje, y la expansión ${ENV_VAR} deja el secreto en el entorno de cada persona y no en el archivo. Escribir el token en línea lo filtra al historial aunque luego se ignore el archivo, y la configuración máquina por máquina se desincroniza porque nada la mantiene alineada.

    Ref. QB-4TKZ9CFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 2: MCP configuration scoping (.mcp.json project scope, ${ENV_VAR} expansion)Reportar un problema con esta pregunta

15. 15. Dos herramientas MCP se describen como "Retrieves customer information" y "Retrieves order details". El agente llama una y otra vez a la equivocada. ¿Cuál es la primera corrección?

    • A.Ampliar cada descripción con formatos de entrada, consultas de ejemplo y límites frente a la herramienta vecina.✓ Respuesta
    • B.Anteponer una capa de enrutado que lea las palabras clave de la petición y la derive a una de las dos.
    • C.Fusionar ambas en una sola herramienta con un parámetro de modo, para que el modelo no tenga que elegir.
    • D.Agregar ejemplos few-shot al prompt de sistema que emparejen peticiones con la herramienta que responde.

    Las descripciones de herramientas son la información principal con la que el modelo elige, así que dos descripciones escuetas y casi idénticas son la causa raíz y no un síntoma. Corregirlas es además el punto de apoyo de menor esfuerzo: una capa de enrutado, una herramienta fusionada con parámetro de modo o ejemplos en el prompt añaden maquinaria alrededor de un defecto que vive en las definiciones mismas.

    Ref. QB-MAS6VCFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 2: tool descriptions as the primary selection mechanismReportar un problema con esta pregunta

16. 16. Una herramienta MCP de consulta devuelve la cadena "Operation failed" tanto cuando el backend agota el tiempo como cuando una búsqueda válida no arroja coincidencias. ¿Cómo deberían reportarse ambos casos?

    • A.Devolver isError en los dos casos y añadir el tiempo transcurrido para que el agente deduzca cuál ocurrió antes de reintentar.
    • B.Devolver isError ante el timeout y lanzar una excepción si no hay coincidencias, para que el agente pare en vez de informar vacío.
    • C.Devolver un resultado exitoso en los dos casos y poner la redacción del fallo en el texto para que el agente lo lea y decida.
    • D.Devolver isError con categoría y bandera de reintento para el timeout, y un resultado vacío exitoso si no hay coincidencias.✓ Respuesta

    Un timeout es un fallo de acceso que deja la respuesta en incógnita y puede merecer reintento, mientras que una consulta que legítimamente no encontró nada es una llamada exitosa con resultado vacío; mezclarlas hace que el agente reintente algo ya resuelto y lea una caída como ausencia. La bandera isError más metadatos estructurados —categoría de error, booleano de reintento, descripción legible— es lo que permite elegir entre reintentar, escalar o informar el vacío.

    Ref. QB-3T8P4BFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 2: MCP error semantics (isError, error metadata, access failure vs empty result)Reportar un problema con esta pregunta

17. 17. Alguien debe encontrar todos los puntos de llamada de una función en un repositorio que no conoce. ¿Qué uso de las herramientas integradas encaja?

    • A.Usar Glob con el patrón de rutas del módulo y luego Read en cada coincidencia para ver dónde se la llama.
    • B.Leer el punto de entrada y cada archivo que importa, ya que solo un recorrido completo garantiza no omitir nada.
    • C.Insertar con Edit una marca en el cuerpo de la función y correr las pruebas para ver qué archivos fallan.
    • D.Usar Grep con el nombre de la función para hallar las llamadas y luego Read en esos archivos para seguir los imports.✓ Respuesta

    Grep busca en el contenido de los archivos, que es donde vive un punto de llamada, mientras que Glob coincide con rutas y nombres y solo hallaría archivos cuyo nombre encaje en un patrón. Explorar de forma incremental —buscar los puntos de entrada y luego leer los archivos concretos que esos aciertos señalan— además evita volcar en el contexto todo lo que una lectura completa arrastraría.

    Ref. QB-KAEUPBFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 2: built-in tools (Grep searches contents, Glob matches paths)Reportar un problema con esta pregunta

18. 18. Un agente de revisión de código tiene instrucciones escritas detalladas, pero sus hallazgos varían de formato y trata los casos ambiguos de manera inconsistente. ¿Qué lo corrige?

    • A.Añadir de dos a cuatro ejemplos con la forma exacta de salida y el razonamiento para elegir una opción sobre otra.✓ Respuesta
    • B.Subir a tres las pasadas de revisión y conservar solo los hallazgos que aparecen en al menos dos de ellas.
    • C.Añadir una instrucción de ser conservador y reportar solo hallazgos de alta confianza, lo que estabiliza la salida.
    • D.Repetir los requisitos de formato al principio y al final del prompt, que es lo que hace que el modelo los cumpla.

    Cuando instrucciones detalladas siguen dando formato y criterio inconsistentes, los ejemplos few-shot son el remedio estándar: muestran la forma exacta de la salida y el razonamiento para elegir una opción frente a otra plausible, y eso generaliza a casos que las instrucciones nunca enumeraron. El lenguaje vago sobre confianza no cambia nada medible, y exigir coincidencia entre corridas suprime hallazgos reales que aparecen de forma intermitente.

    Ref. QB-2TVBX9Fuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 4: few-shot examples for format consistency and ambiguous-case judgmentReportar un problema con esta pregunta

19. 19. Las facturas se extraen mediante una llamada a herramienta con un esquema JSON estricto. El JSON siempre parsea, pero las validaciones posteriores siguen rechazando registros cuyas partidas no cuadran. ¿Por qué?

    • A.El esquema se aplica tras la generación, así que los campos numéricos pasan a texto y fallan los cálculos.
    • B.El esquema restringe la forma de la salida, no su verdad, así que partidas que no suman igual validan.✓ Respuesta
    • C.El esquema prohíbe campos opcionales, así que el modelo inventa totales para llenar claves obligatorias.
    • D.El esquema es orientativo para el modelo, así que aún cabe JSON malformado y hay que repararlo antes.

    Una llamada a herramienta con esquema JSON es la vía más fiable para obtener salida conforme al esquema y elimina errores de sintaxis y estructura, pero no dice nada sobre si los valores son correctos, así que errores semánticos como un total mal sumado o un valor en el campo equivocado pasan intactos. Detectarlos exige autovalidación en el propio esquema —por ejemplo extraer el total declarado y el total calculado más una bandera de conflicto— y una comprobación posterior.

    Ref. QB-JA3HHAFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 4: schema-constrained tool use eliminates syntax errors, not semantic errorsReportar un problema con esta pregunta

20. 20. Llegan documentos de tipo desconocido y hay una herramienta de extracción por tipo. A veces el modelo responde en prosa en lugar de extraer nada. ¿Qué ajuste corresponde?

    • A.Poner tool_choice en any, que obliga a llamar una herramienta pero deja al modelo elegir cuál.✓ Respuesta
    • B.Poner tool_choice en auto, que permite responder en prosa cuando ningún esquema encaja bien.
    • C.Dejar tool_choice sin fijar y pedir en el prompt que siempre llame a una herramienta, y lo hará.
    • D.Forzar siempre el mismo extractor y dejar que el modelo marque el desajuste en algún campo.

    tool_choice "any" obliga al modelo a llamar alguna herramienta pero le deja elegir cuál, que es justo el caso con varios esquemas de extracción y un tipo de documento desconocido de antemano. "auto" permite una respuesta en texto, forzar una herramienta concreta aplica el esquema equivocado cuando el tipo difiere, y una exigencia en el prompt es una petición probabilística, no una restricción sobre la respuesta.

    Ref. QB-3RAH4BFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 4: tool_choice auto vs any vs a forced named toolReportar un problema con esta pregunta

21. 21. Una sesión larga de refactorización se acerca al límite de su contexto. ¿Cuál es la diferencia entre compactarla y limpiarla?

    • A.Ambas resumen el historial; una se lanza a demanda y la otra al superarse cierto tamaño de sesión.
    • B.La compactación tira los mensajes más antiguos; limpiar guarda un resumen para poder continuar el hilo.
    • C.La compactación borra los resultados de herramientas y deja la prosa; limpiar hace justo lo contrario.
    • D.La compactación cambia el historial por un resumen y sigue el hilo; limpiar lo descarta y empieza vacío.✓ Respuesta

    La compactación resume la conversación hasta ese punto y continúa desde el resumen, lo que libera espacio pero pierde información: los valores precisos como rutas, cifras y decisiones se difuminan primero, así que lo que deba sobrevivir conviene reescribirlo o guardarlo en un archivo de notas. Limpiar descarta el historial y empieza de cero, que es lo indicado cuando el material previo está obsoleto y no simplemente abultado.

    Ref. QB-J85CHAFuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 5: context management (/compact summarises and continues, clearing discards)Reportar un problema con esta pregunta

22. 22. Un equipo evalúa una herramienta de codificación agéntica que edita una rama compartida directamente y no deja diff, registro ni constancia de los comandos ejecutados. ¿Cuál es la razón más fuerte para no adoptarla?

    • A.Sus cambios llegan más rápido de lo que los revisores pueden leer, así que la cola de revisión no dejará de crecer.
    • B.Sus cambios provienen de un modelo y no de una persona, así que quedan fuera de las reglas de propiedad del código.
    • C.Sus cambios no pueden inspeccionarse como diff, así que nadie puede separar un cambio correcto de uno erróneo.✓ Respuesta
    • D.Sus cambios dependen de un modelo cuyo comportamiento varía entre versiones, y un prompt puede no reproducir el diff.

    La salida de un agente es una propuesta, no un cambio verificado, y todo el modelo de seguridad descansa en que una persona pueda inspeccionar qué se modificó y qué se ejecutó antes de que sea definitivo. Una herramienta cuyo trabajo no se puede revisar renuncia por completo a ese control, y ninguna capacidad lo compensa; las demás objeciones son problemas reales de gestión, pero se sobrellevan si existe una traza revisable.

    Ref. QB-2RX6X9Fuente: CCAR-F Exam Guide v1.0 (July 2026), Domain 3 / Domain 5: reviewability and auditability of agent-produced changesReportar un problema con esta pregunta

Preguntas de práctica basadas en la guía oficial del examen Claude Certified Architect – Foundations (CCAR-F) y la documentación pública de Anthropic. Es una herramienta de estudio independiente, no afiliada ni respaldada por Anthropic, y no otorga certificación. Lo administra Pearson VUE; Anthropic publica el número de preguntas, el límite de tiempo, la puntuación de aprobación y la tarifa vigentes en la guía oficial del examen CCAR-F. Página oficial de la certificación →