App de Quibank: ya está en el App Store — gratis y sin conexión. Descargar ↗

22 Preguntas de Práctica de Aplicaciones e integración de API con Respuestas

Todas las preguntas de práctica de Aplicaciones e integración de API del Examen de práctica Claude Certified Developer – Foundations, con la respuesta correcta y una breve explicación.

Comenzar examen de práctica →
  1. 1. Una aplicación mantiene un chat de varios turnos con Claude. Cuando envía el cuarto turno de usuario a la Messages API, ¿qué debe contener el cuerpo de la solicitud?

    • A.Un resumen breve de los turnos anteriores; el historial completo solo se acepta en la primera solicitud
    • B.Solo el mensaje de usuario más reciente, porque el servicio guarda los turnos anteriores bajo un ID de conversación
    • C.El mensaje más reciente más el ID de la respuesta anterior, que el servicio expande del lado del servidor
    • D.El historial completo y ordenado de turnos previos de usuario y asistente, seguido del nuevo mensaje✓ Respuesta

    La Messages API es sin estado: no guarda ningún registro de la conversación entre llamadas, así que el modelo solo ve lo que trae la solicitud actual. El cliente es dueño del historial y debe reenviar el arreglo messages completo y ordenado —incluidas las respuestas previas del asistente— en cada turno.

    Ref. QB-ZX7SQ6Fuente: Anthropic docs — Messages API overview (stateless requests)Reportar un problema con esta pregunta

  2. 2. Un desarrollador arma un arreglo messages cuya primera entrada tiene el rol assistant, seguida de una entrada user. ¿Cuál es el resultado documentado?

    • A.La API reordena silenciosamente el arreglo para que la entrada user quede primero
    • B.La solicitud se rechaza con un error de solicitud inválida✓ Respuesta
    • C.La entrada assistant se trata como el prompt de sistema
    • D.La solicitud tiene éxito y la entrada assistant se usa como ejemplo de estilo

    Una conversación siempre comienza con un turno de usuario, así que un arreglo messages que empieza con assistant es una solicitud malformada y se rechaza con un error de solicitud inválida (4xx) en lugar de corregirse. Las entradas assistant sí son válidas más adelante en el arreglo, por ejemplo como ejemplos few-shot.

    Ref. QB-FFP9Y4Fuente: Anthropic docs — Messages API, message rolesReportar un problema con esta pregunta

  3. 3. Un cliente añade dos entradas consecutivas con rol user a messages antes de llamar a la API. ¿Cómo las trata la API?

    • A.Solo se envía la última al modelo y la anterior se descarta
    • B.La solicitud se rechaza porque debe insertarse una entrada assistant entre ellas
    • C.Se combinan en un solo turno de usuario✓ Respuesta
    • D.Cada una provoca una respuesta separada del asistente en la misma solicitud

    Las entradas consecutivas con el mismo rol se fusionan en un solo turno, así que no se pierde nada ni se genera un error. Esto importa cuando el código añade contexto (por ejemplo un documento recuperado) como su propia entrada de usuario justo antes de la pregunta real: ambas llegan como un único turno, en orden.

    Ref. QB-YXUEJ5Fuente: Anthropic docs — working with Messages (consecutive same-role messages)Reportar un problema con esta pregunta

  4. 4. ¿Dónde deben colocarse las instrucciones que definen el rol del asistente y deben regir toda la conversación?

    • A.En un tipo de bloque de contenido dedicado que puede aparecer en cualquier lugar dentro de un turno de assistant
    • B.En el parámetro system de nivel superior de la solicitud, que va fuera del arreglo messages✓ Respuesta
    • C.Anteponiéndolas al texto de cada mensaje de usuario para que el modelo las vea en cada turno
    • D.Como la primera entrada del arreglo messages con rol system, que debe ser siempre messages[0]

    Las instrucciones de sistema son un parámetro de nivel superior de la solicitud, separado estructuralmente de los turnos de conversación, y por eso rigen todo el intercambio sin confundirse con la entrada del usuario. Meterlas dentro de los turnos de usuario funciona peor y mezcla instrucciones del operador con texto no confiable.

    Ref. QB-EFBXS3Fuente: Anthropic docs — Messages API, system promptsReportar un problema con esta pregunta

  5. 5. ¿Cuál afirmación describe mejor el campo content de un mensaje en la Messages API?

    • A.Es un mapa clave/valor cuyas claves nombran la modalidad de cada parte
    • B.Siempre debe ser una cadena de texto; la entrada no textual requiere otro endpoint
    • C.Es una cadena simple o una lista ordenada de bloques de contenido tipados✓ Respuesta
    • D.Es una cadena para los turnos de usuario y siempre una lista de bloques para los turnos de assistant

    El contenido es una lista de bloques tipados; la forma de cadena simple es solo una abreviatura de un único bloque de texto. Ese diseño por bloques es lo que permite que un turno mezcle texto, imágenes, documentos, llamadas a herramientas y resultados, manteniendo su orden explícito.

    Ref. QB-XXG4D4Fuente: Anthropic docs — Messages API, content blocksReportar un problema con esta pregunta

  6. 6. ¿Por qué es frágil leer una respuesta tomando el texto del primer elemento de content?

    • A.Porque el primer elemento siempre está reservado para metadatos de la respuesta
    • B.Porque la respuesta puede tener varios tipos de bloque y el texto no necesariamente es el primero✓ Respuesta
    • C.Porque content se devuelve en orden inverso, así que la respuesta final siempre va al final
    • D.Porque content solo se llena cuando el streaming está desactivado

    Una sola respuesta es un arreglo que puede contener varios bloques de tipos mezclados —por ejemplo un bloque de uso de herramienta, o texto citado y no citado repartido en bloques—, así que la posición cero no es de forma fiable el texto de la respuesta. El código robusto recorre el arreglo y actúa según el tipo declarado de cada bloque.

    Ref. QB-DFYKM2Fuente: Anthropic docs — Messages API response formatReportar un problema con esta pregunta

  7. 7. Una aplicación debe enviar a Claude una captura de pantalla guardada localmente para que la describa. ¿Cómo se entrega la imagen?

    • A.Como un bloque de texto con la ruta absoluta del archivo, que la API lee del sistema de archivos del cliente
    • B.Como un bloque de contenido image con los datos en base64 y su tipo de medio✓ Respuesta
    • C.Como binario crudo añadido después del cuerpo JSON, mediante una solicitud multipart
    • D.Como un bloque de texto con la cadena base64, ya que el modelo detecta el formato automáticamente

    Las imágenes locales viajan dentro del cuerpo JSON como un bloque image cuyo source en base64 declara el tipo de medio explícitamente; la API no deduce el formato ni accede al sistema de archivos del cliente. Una imagen accesible públicamente puede darse como source de tipo URL, y un archivo ya subido como referencia de archivo.

    Ref. QB-WX5S73Fuente: Anthropic docs — vision (image content blocks)Reportar un problema con esta pregunta

  8. 8. Un turno de usuario contiene un bloque de imagen y un bloque de texto que pregunta sobre esa imagen. ¿Cuál es la práctica recomendada en cuanto a su orden?

    • A.Separarlos en dos turnos de usuario distintos, primero la imagen y luego el texto
    • B.Colocar el bloque de texto antes del bloque de imagen
    • C.El orden lo impone la API, que siempre mueve las imágenes al final
    • D.Colocar el bloque de imagen antes del bloque de texto✓ Respuesta

    Los bloques se procesan en el orden dado, y poner la imagen primero hace que la pregunta se lea con la evidencia visual ya en contexto, lo que mejora los resultados de forma medible. La API no reordena bloques, así que el orden es responsabilidad del llamador.

    Ref. QB-MFFXTAFuente: Anthropic docs — vision, prompt structure best practicesReportar un problema con esta pregunta

  9. 9. Se debe analizar un contrato en PDF en una sola solicitud a la Messages API. ¿Cómo se entrega?

    • A.Como una cadena de bloques de imagen que el llamador debe renderizar, uno por página, antes de enviar
    • B.Mediante un endpoint de documentos dedicado que devuelve un identificador para un mensaje posterior
    • C.Como un bloque document cuyo source es base64, una URL o un archivo ya subido✓ Respuesta
    • D.Como un bloque de texto con el texto que el llamador extrajo, única forma admitida

    Los PDF viajan en el mismo arreglo messages que todo lo demás, como bloque document, y su source puede ser base64 en línea, una URL o una referencia a un archivo: no hace falta un endpoint aparte ni renderizar páginas a mano. Como cada página se procesa visualmente y como texto, los documentos con mucho diseño, como los contratos, siguen siendo interpretables.

    Ref. QB-5YM4EBFuente: Anthropic docs — PDF support (document content blocks)Reportar un problema con esta pregunta

  10. 10. Un bucle de agente envía la misma imagen de referencia grande en cada uno de sus muchos turnos y los cuerpos de solicitud se han vuelto enormes. ¿Qué cambio ataca la causa?

    • A.Enviar la imagen solo en el primer turno y confiar en que la API la recuerde durante el resto de la conversación
    • B.Subir la imagen una sola vez por el endpoint de archivos y referenciar el identificador devuelto en cada solicitud posterior✓ Respuesta
    • C.Comprimir con gzip la cadena base64 dentro del campo JSON antes de enviarla
    • D.Mover la imagen al parámetro system, que queda excluido del tamaño del cuerpo de la solicitud

    Como la API es sin estado, el contenido base64 en línea se vuelve a subir en cada turno; subirlo una vez y referenciar el identificador devuelto mantiene pequeños los cuerpos posteriores. El patrón de subir una vez y referenciar muchas es justamente para lo que existe el endpoint de archivos, y el identificador se puede reutilizar en muchas solicitudes.

    Ref. QB-BVG7DRFuente: Anthropic docs — Files APIReportar un problema con esta pregunta

  11. 11. Tras subir un PNG y un PDF y recibir un identificador para cada uno, ¿cómo se referencian en una solicitud posterior a Messages?

    • A.Ambos como bloques image, ya que el identificador ya codifica el tipo de medio
    • B.Ambos como bloques document, ya que todo archivo subido se trata como documento
    • C.El PNG como bloque image y el PDF como bloque document✓ Respuesta
    • D.Como bloques de texto con las cadenas de identificador, que la API sustituye por el contenido

    El identificador de archivo no cambia cómo se tipa el contenido: el tipo de bloque debe coincidir con el tipo de medio del archivo, así que las imágenes van en bloques image y los PDF o texto plano en bloques document. Un tipo de bloque que no coincide se rechaza como solicitud inválida en lugar de convertirse silenciosamente.

    Ref. QB-TCB2TQFuente: Anthropic docs — Files API, referencing files in MessagesReportar un problema con esta pregunta

  12. 12. Un producto debe mostrar qué pasaje del documento aportado respalda cada afirmación de la respuesta de Claude. ¿Cuál es el mecanismo correcto?

    • A.Pedir en el prompt citas con números de página, única forma admitida de obtener referencias
    • B.Activar citations en el bloque de contenido document✓ Respuesta
    • C.Llamar después a un endpoint de citas aparte, pasando el identificador de la respuesta
    • D.Las citas se generan automáticamente para todo documento, así que no hace falta cambiar la solicitud

    Las citas son una opción que se activa en cada bloque document, y activarlas cambia la forma de la respuesta: esta llega como varios bloques de texto, donde los citados llevan referencias estructuradas que localizan el fragmento de apoyo en la fuente. Esa estructura permite a una interfaz resaltar la evidencia de forma fiable, en vez de confiar en citas en texto libre que el modelo podría parafrasear.

    Ref. QB-CVUHJSFuente: Anthropic docs — citationsReportar un problema con esta pregunta

  13. 13. Un trabajo nocturno clasifica decenas de miles de documentos. Ningún resultado se necesita hasta la mañana siguiente y el costo por documento importa. ¿Qué enfoque encaja mejor?

    • A.Repartir los documentos en solicitudes síncronas paralelas para terminar tan rápido como permitan los límites de tasa
    • B.Enviar el trabajo como un lote asíncrono, que se factura con descuento✓ Respuesta
    • C.Mantener solicitudes síncronas pero cambiar al modelo más barato disponible sin evaluar la calidad
    • D.Mantener solicitudes síncronas pero reducir mucho el límite de tokens de salida de cada una para abaratar

    La regla de decisión es si realmente se requiere baja latencia; cuando no es así y el volumen es alto, el endpoint de lotes asíncrono es el camino previsto, porque cambia tiempo de entrega por menor precio. Los tres distractores mantienen la vía en tiempo real y buscan ahorro en otro lado: el paralelismo solo consume límites de tasa, recortar el tope de salida trunca respuestas, y degradar el modelo sin evaluación sacrifica exactitud a ciegas.

    Ref. QB-UCPCYRFuente: Anthropic docs — Message Batches API overview (batch vs realtime)Reportar un problema con esta pregunta

  14. 14. ¿Cuál es el ciclo de vida correcto para ejecutar trabajo por el endpoint de lotes asíncrono?

    • A.Enviar el lote y leer los resultados directamente de la respuesta de creación, que bloquea hasta que estén listos
    • B.Enviar el lote, sondear su estado de procesamiento hasta que indique que terminó, y luego leer los resultados✓ Respuesta
    • C.Enviar cada solicitud por separado y sondear cada una por su propio identificador hasta completarse
    • D.Enviar el lote y esperar a que el servicio abra una conexión hacia el cliente con los resultados

    El procesamiento por lotes es asíncrono por diseño: la creación devuelve de inmediato un identificador de lote y un estado de procesamiento, así que el cliente sondea ese estado y solo recupera los resultados cuando el procesamiento ha terminado. Nada bloquea y el servicio no llama de vuelta al cliente, por eso el endpoint sirve para trabajos mucho más largos que cualquier solicitud HTTP.

    Ref. QB-9VSH2PFuente: Anthropic docs — Message Batches API, polling for completionReportar un problema con esta pregunta

  15. 15. Se leen los resultados de un lote finalizado. ¿Cómo debe emparejarse cada resultado con la solicitud que lo generó?

    • A.Comparando el texto de cada resultado con los prompts originales para hallar la coincidencia más cercana
    • B.Por el identificador elegido por el llamador que lleva cada solicitud✓ Respuesta
    • C.Por el orden en que terminaron las solicitudes, que el servicio informa por separado
    • D.Por posición, ya que los resultados vuelven en el mismo orden en que se enviaron

    Cada entrada de un lote lleva un identificador elegido por el llamador justamente para poder reasociar los resultados, y el flujo de resultados devuelve ese identificador en cada entrada. El orden no está garantizado, así que el código que empareja resultados por índice adjuntará silenciosamente respuestas a los registros equivocados.

    Ref. QB-RCMCFNFuente: Anthropic docs — Message Batches API, retrieving resultsReportar un problema con esta pregunta

  16. 16. ¿Por qué se recomienda el streaming para solicitudes que producirán una respuesta muy larga?

    • A.Porque el streaming eleva el número máximo de tokens de salida que el modelo puede producir
    • B.Porque las solicitudes sin streaming se rechazan de plano cuando la respuesta sería larga
    • C.Porque sin streaming la conexión queda inactiva y arriesga un timeout HTTP del cliente o proxy✓ Respuesta
    • D.Porque los tokens transmitidos en streaming se facturan más barato que los que no

    Sin streaming, el servidor no envía nada hasta terminar la generación, así que una generación larga puede superar el timeout del cliente HTTP o de un intermediario y la solicitud falla aunque el trabajo ya se hizo. El streaming emite eventos de forma continua, mantiene la conexión activa y permite al cliente mostrar la salida parcial conforme llega.

    Ref. QB-AV5V7QFuente: Anthropic docs — streaming MessagesReportar un problema con esta pregunta

  17. 17. Para una respuesta en streaming con un solo bloque de texto, ¿qué secuencia de eventos coincide con la estructura documentada?

    • A.Pares repetidos de inicio y fin de mensaje, uno por cada fragmento de texto
    • B.Inicio de bloque de contenido, luego inicio de mensaje, después los deltas y el fin de mensaje
    • C.Inicio de mensaje, inicio de bloque, deltas de texto, fin de bloque, delta de mensaje y fin de mensaje✓ Respuesta
    • D.Un único inicio de mensaje con el contenido ya completo, seguido del fin de mensaje

    El flujo abre con un evento de inicio de mensaje cuyo contenido viene vacío; luego cada bloque de contenido se envuelve en un evento de inicio, uno o más deltas incrementales y un evento de fin, y por último llegan las actualizaciones a nivel de mensaje y el fin de mensaje. Manejar los eventos según esa estructura, en vez de suponer que el texto llega suelto, es lo que hace que el consumidor funcione también con respuestas de varios bloques y con uso de herramientas.

    Ref. QB-SCYPMPFuente: Anthropic docs — streaming, event flowReportar un problema con esta pregunta

  18. 18. Un cliente recibe una respuesta en streaming y necesita saber por qué se detuvo la generación. ¿Dónde llega esa información?

    • A.En el delta a nivel de mensaje cerca del final del flujo✓ Respuesta
    • B.En cada evento de fin de bloque de contenido, uno por bloque
    • C.Solo repitiendo el mismo prompt en una segunda solicitud sin streaming
    • D.En el evento de inicio de mensaje, que ya informa cómo terminará el mensaje

    El evento inicial trae un envoltorio de mensaje con contenido vacío y sin razón de parada final, porque la generación aún no ha ocurrido; la razón de parada es un campo de nivel superior que solo se conoce al final, así que se entrega en el delta a nivel de mensaje. Suponer que está disponible desde el inicio produce código que nunca detecta que la respuesta quedó, por ejemplo, cortada por el límite de salida.

    Ref. QB-FVWH3WFuente: Anthropic docs — streaming, message_delta eventReportar un problema con esta pregunta

  19. 19. ¿Cuál emparejamiento entre un código de estado HTTP devuelto por la API y su causa es correcto?

    • A.429 — la clave del llamador no tiene permiso para el recurso solicitado
    • B.401 — las credenciales faltan o son inválidas✓ Respuesta
    • C.404 — el cuerpo JSON de la solicitud estaba malformado
    • D.413 — el servicio está temporalmente sobrecargado

    401 indica un problema de autenticación —credencial ausente, mal formada o revocada— y se distingue de 403, que significa credencial válida pero sin permiso para ese recurso. Las demás opciones intercambian códigos conocidos: un cuerpo malformado es 400, exceder el límite de tasa es 429, una solicitud demasiado grande es 413, y la sobrecarga se informa con un estado 5xx del servidor.

    Ref. QB-XCRCGVFuente: Anthropic docs — API errors (HTTP status codes)Reportar un problema con esta pregunta

  20. 20. ¿Qué fallos debe reintentar un cliente con backoff en lugar de tratarlos como permanentes?

    • A.Las respuestas de solicitud demasiado grande, que tendrán éxito cuando el servicio tenga capacidad
    • B.Las respuestas por límite de tasa y los errores del lado del servidor, incluido el estado de sobrecarga✓ Respuesta
    • C.Los fallos de autenticación y de permisos, que suelen resolverse solos en un momento
    • D.Las respuestas de solicitud malformada y de recurso no encontrado, porque el endpoint podría aparecer luego

    Reintentar solo ayuda cuando el fallo es transitorio —la solicitud es válida y un intento posterior puede funcionar—, como ocurre con el límite de tasa, los errores pasajeros del servidor y la sobrecarga. Credenciales incorrectas, permisos faltantes, cuerpos malformados, recursos inexistentes y cargas demasiado grandes describen un problema en la propia solicitud, así que reintentar igual seguirá fallando y solo añade carga.

    Ref. QB-GMFPJKFuente: Anthropic docs — API errors, retryable errorsReportar un problema con esta pregunta

  21. 21. Una solicitud se rechaza por superar el límite de tasa y la respuesta incluye una cabecera retry-after. ¿Cuál es el comportamiento correcto del cliente?

    • A.Reintentar de inmediato en un bucle cerrado hasta que un intento sea aceptado
    • B.Tratarlo como fallo permanente y descartar la solicitud, porque los límites de tasa no se restablecen
    • C.Ignorar retry-after y reintentar a intervalos cortos fijos, ya que la cabecera solo orienta a los navegadores
    • D.Esperar al menos lo que indique retry-after y reintentar con backoff exponencial, jitter y un tope de intentos✓ Respuesta

    Los límites de tasa se recuperan con el tiempo, así que la solicitud es reintentable, pero solo tras el intervalo que el propio servidor indica en retry-after, con esperas que crecen exponencialmente y jitter para que muchos clientes no se sincronicen en otro pico. Reintentar de inmediato en bucle agrava la limitación en vez de resolverla, y un tope de intentos evita que un fallo persistente cicle para siempre.

    Ref. QB-Z4NU5MFuente: Anthropic docs — API errors and rate limits (retry-after)Reportar un problema con esta pregunta

  22. 22. ¿Cómo debe una integración distinguir entre las distintas condiciones de error que puede lanzar el SDK?

    • A.Capturar las clases de excepción tipadas del SDK, de la más específica a la más general, terminando con la clase base✓ Respuesta
    • B.Dejar que todas las excepciones se propaguen y confiar en que el SDK reintente todo automáticamente
    • C.Analizar la representación impresa de la excepción para recuperar el código de estado
    • D.Capturar una única excepción base amplia e inspeccionar el texto del mensaje buscando subcadenas como rate limit o not found

    El SDK define una clase de excepción distinta por condición de error justamente para que el llamador ramifique por tipo, y ordenar los manejadores de lo más específico a lo más general evita que la clase base absorba un caso concreto. Emparejar por el texto del mensaje es frágil, porque la redacción no forma parte del contrato de la API y puede cambiar sin aviso, y un único catch general descarta la distinción entre reintentable y permanente que codifican esas clases.

    Ref. QB-HMTZQMFuente: Anthropic docs — SDK error handling (typed exceptions)Reportar un problema con esta pregunta

Otros temas de este examen

Preguntas de práctica basadas en la guía oficial del examen Claude Certified Developer – Foundations (CCDV-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 CCDV-F. Página oficial de la certificación →