Microsoft AZ-204: Gestión de API de Azure — Guía de estudio

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Developer Associate AZ-204 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Descripción general

Azure API Management (APIM) proporciona una fachada unificada sobre diversos servicios de backend, combinando una puerta de enlace de alto rendimiento con un motor de directivas configurable, la incorporación de desarrolladores y un plano de administración completo. Permite controles consistentes de seguridad, limitación de velocidad (throttling), transformación, observabilidad y ciclo de vida en backends REST, SOAP y GraphQL. APIM es tanto una puerta de enlace en tiempo de ejecución para el tráfico como un sistema impulsado por configuración que se administra a través del portal de Azure, ARM/Bicep/CLI o CI/CD. Comprender la canalización de solicitudes, las capacidades de las directivas, el control de versiones/revisiones, el modelo de suscripción y las características de los niveles es fundamental para construir API robustas y seguras a escala.

Arquitectura, niveles y componentes principales

La puerta de enlace es el plano de datos. Termina las conexiones de los clientes, aplica directivas en un orden determinista, enruta a los backends y devuelve las respuestas. Soporta almacenamiento en caché integrado, validación de JWT, TLS mutuo y transformación de contenido a velocidad de línea. Las puertas de enlace pueden ser alojadas por Microsoft por región o autohospedadas (en contenedores) para ejecutarse más cerca de cargas de trabajo locales (on-premises) o en el borde, sin dejar de ser administradas centralmente. La puerta de enlace expone trazas y métricas y se integra con Application Insights para telemetría distribuida.

El portal para desarrolladores es la experiencia de cara al consumidor para el descubrimiento, la documentación y la gestión de suscripciones. Renderiza la documentación de OpenAPI/GraphQL, proporciona consolas interactivas para “probar”, maneja flujos de OAuth 2.0 en el navegador y soporta personalización de marca y proveedores de identidad. Los desarrolladores autogestionan las suscripciones a productos y rotan las claves aquí.

El plano de administración es la superficie de configuración y gobernanza. Almacena API, operaciones, directivas, productos, usuarios/grupos, backends, certificados y diagnósticos. Es accesible a través del portal de Azure, ARM/Bicep/CLI/PowerShell, la API REST de administración y la sincronización de configuración basada en Git. Este plano orquesta los despliegues, el control de versiones, las revisiones y el RBAC.

Los niveles de APIM determinan la escala, las características y las capacidades de red:

Consumption es sin servidor (serverless) y se factura por llamada. Escala automáticamente, es ideal para escenarios con picos de tráfico o de bajo rendimiento, y soporta la mayoría de las directivas principales. No incluye almacenamiento en caché de respuestas integrado y carece de características avanzadas de red y multirregión.
Developer es para entornos de no producción. Ofrece una funcionalidad casi completa sin un SLA y sin el rendimiento a escala de producción.
Basic y Standard son niveles de producción dedicados y de una sola región con rendimiento predecible, unidades de escalado horizontal y almacenamiento en caché de respuestas integrado. Son adecuados para muchas cargas de trabajo empresariales que no requieren multirregión ni redes avanzadas.
Premium añade despliegue multirregión, redes avanzadas (incluida la integración con VNet), mayor escala, zonas de disponibilidad en regiones compatibles y licencias para puertas de enlace autohospedadas. Elija Premium para despliegues globales, de misión crítica y redes privadas.

Directivas y la canalización de solicitudes

Las directivas de APIM son declaraciones declarativas que se ejecutan en un orden estricto a través de cuatro secciones: entrada (inbound), backend, salida (outbound) y en caso de error (on-error).

Las directivas de entrada (inbound) se ejecutan antes de que la solicitud se reenvíe al backend. Las tareas típicas incluyen requerir o validar claves de suscripción, validar JWT (forzando emisor, audiencia, firma), verificar IP de cliente, aplicar límites de velocidad y cuotas, normalizar encabezados, reescribir URI y transformar la carga útil (payload). Puede enrutar condicionalmente a diferentes backends y establecer variables para etapas posteriores.

La sección de backend configura y modifica la llamada al servicio ascendente. Úsela para seleccionar una entidad de backend, adjuntar credenciales de cliente (autenticación básica, certificados de cliente o tokens adquiridos mediante identidad administrada para backends protegidos por Azure AD), establecer tiempos de espera, habilitar reintentos y aplicar la interrupción de circuito (circuit breaking). El TLS mutuo con el backend se configura aquí asociando un certificado de cliente que la puerta de enlace presentará.

Las directivas de salida (outbound) se ejecutan después de recibir la respuesta del backend. Comúnmente realizan transformaciones de respuesta (p. ej., de JSON a XML o viceversa), reescritura de encabezados, modelado de datos, enmascaramiento de detalles internos y almacenamiento en caché de la respuesta. Este es también el lugar para aplicar conversiones de negociación de contenido o para normalizar los códigos de estado.

Las directivas “en caso de error” (on-error) se ejecutan si ocurre una excepción en cualquier sección anterior, incluida la llamada al backend. Use esta sección para mapear errores del backend a formatos de error de API estandarizados, establecer códigos de estado apropiados, redactar mensajes sensibles, agregar ID de correlación o proporcionar respuestas de respaldo.

Patrones de directivas comunes:

La limitación de velocidad (rate limiting) controla el rendimiento en ráfagas y protege los backends. rate-limit-by-key impone una limitación por identidad utilizando una clave como la clave de suscripción, una notificación (claim) de JWT o la IP. Para ventanas de tiempo más largas, combine con quota-by-key para limitar el uso diario o mensual.
El filtrado de IP bloquea o permite el tráfico por IP de cliente o rangos CIDR usando ip-filter, a menudo posicionado al principio de la sección de entrada (inbound) para minimizar el costo y la exposición.
La validación de JWT con validate-jwt impone los parámetros de OpenID Connect. Configure la URL de configuración de OpenID o el emisor, defina las audiencias/ámbitos (scopes) aceptados, seleccione las notificaciones (claims) requeridas y ajuste el desfase de reloj y las comprobaciones de vida útil del token. Deniegue el acceso anónimo requiriendo un token válido para todas las operaciones donde no se permitan llamadas anónimas.
La transformación incluye rewrite-uri, set-header, set-query-parameter, set-body y find-and-replace. Use xml-to-json o json-to-xml para conectar formatos de cliente/backend que no coinciden sin cambiar el código.
El almacenamiento en caché aprovecha cache-lookup y cache-store para almacenar en caché respuestas completas basándose en claves que pueden incluir la ruta, la consulta, los encabezados y las notificaciones (claims) de JWT. Use cache-lookup-value/cache-store-value para el almacenamiento en caché de clave/valor dentro de las directivas, como para almacenar tokens en caché. Tenga en cuenta que el almacenamiento en caché de respuestas integrado no está disponible en el nivel Consumption.

Seguridad, identidad y suscripciones

Se debe abordar tanto la seguridad del cliente al gateway en el front-end como la seguridad del gateway al servicio en el back-end.

Para la seguridad del front-end, el patrón dominante es OAuth 2.0 con Azure AD. Los clientes adquieren tokens de Azure AD y los presentan al gateway. APIM impone los requisitos de los tokens usando validate-jwt que hace referencia a los metadatos de OpenID Connect de Azure AD (el well-known endpoint del tenant). Las directivas pueden aplicar comprobaciones de audiencia (audience) para asegurar que el token se dirige a la API correcta, notificaciones de ámbito (scope claims) para asegurar que quienes llaman tienen los permisos apropiados, y notificaciones opcionales (optional claims) como los roles de aplicación. Para eliminar las llamadas anónimas, se debe aplicar validate-jwt a todas las operaciones. El portal para desarrolladores se puede configurar con Azure AD para simplificar la adquisición de tokens durante las pruebas.

Para los certificados de cliente y el TLS mutuo (mTLS), APIM puede requerir certificados de cliente entrantes de quienes llaman, validando emisor/asunto/caducidad y, opcionalmente, el estado de CRL/OCSP usando validate-client-certificate. Esto es adecuado para integraciones B2B y de alta seguridad. Para el mTLS del gateway al backend, cargue un certificado de cliente en APIM, asócielo con una entidad de backend o con set-backend-service, y APIM lo presentará durante el handshake de TLS para autenticarse en el backend. Este enfoque es a menudo requerido por App Service protegidos o servicios personalizados que exigen autenticación por certificado.

Para los backends protegidos con Azure AD, use authentication-managed-identity en la sección de backend para adquirir un token de acceso con la identidad administrada asignada por el sistema o por el usuario de APIM. La directiva inyecta el encabezado Authorization para la llamada al backend. Esto evita almacenar secretos y cumple con los requisitos modernos de confianza cero (zero-trust).

Las suscripciones proporcionan un modelo de acceso y monetización de grano grueso. Los productos son paquetes de API regidos por términos, aprobación y límites de uso. Los desarrolladores se suscriben a los productos para obtener claves de suscripción (primaria y secundaria) que se usan a través del encabezado Ocp-Apim-Subscription-Key o un parámetro de consulta. Las claves se pueden rotar sin tiempo de inactividad gracias a las claves duales. El ámbito de la suscripción determina dónde se aplican las claves: a todas las API, a una única API o a un producto específico. El acceso basado en suscripciones es complementario a OAuth 2.0; se pueden requerir ambos, lo que permite una limitación (throttling) y una contabilidad independientes mientras que la autenticación se basa en tokens. Los productos pueden aplicar cuotas y límites de velocidad por suscripción que son independientes de las directivas por operación, proporcionando una protección y gobernanza por capas.

Backends, resiliencia, control de versiones y revisiones

Los backends en APIM son entidades reutilizables de primera clase que encapsulan la URL base de un servicio de destino, el protocolo, las credenciales, la configuración de TLS, las plantillas de encabezado y la configuración del proxy. Asociar API y operaciones con backends desacopla el enrutamiento de las directivas y centraliza los detalles de conexión. Usa

undefined

por ID de backend en las directivas para enrutar solicitudes sin codificar URL de forma fija, simplificando la promoción entre entornos de desarrollo, pruebas y producción.

La resiliencia se implementa con reintentos y el patrón de disyuntor (circuit breaker). Los reintentos con retroceso exponencial (exponential backoff) pueden mitigar fallos transitorios; deben limitarse a operaciones idempotentes y estar acotados por tiempos de espera razonables para evitar la amplificación. Una directiva de disyuntor se abre cuando la tasa de fallos, los fallos consecutivos o la latencia superan los umbrales configurados dentro de una ventana de muestreo, cortocircuitando las solicitudes durante una duración de interrupción definida. Durante el estado abierto, la directiva puede devolver inmediatamente una respuesta de respaldo (fallback) o enrutar a un backend en espera (standby). Cuando está semiabierto, un número limitado de solicitudes de prueba sondea la salud del backend antes de cerrar el circuito. Esto protege los backends, mejora la experiencia del cliente y estabiliza los sistemas bajo fallos parciales.

El balanceo de carga y el enrutamiento se pueden implementar en la capa de directivas. El enrutamiento condicional con choose puede dirigir el tráfico por segmento de usuario, geografía, contenido de la solicitud o señales de salud. El enrutamiento ponderado se puede lograr mediante expresiones de directiva que seleccionan un backend de forma pseudoaleatoria según los pesos deseados, lo que permite lanzamientos canary y despliegues graduales. Los backends activo-activo entre regiones se pueden gestionar con un despliegue multirregional de APIM de nivel Premium combinado con enrutamiento condicional a la región saludable más cercana; alternativamente, se puede integrar con Azure Front Door para el balanceo de carga global de capa 7, mientras que APIM se encarga de la autenticación y la transformación.

El control de versiones y las revisiones gobiernan el ciclo de vida de la API. Los conjuntos de versiones (version sets) definen cómo se exponen múltiples versiones de una API a los clientes, utilizando un esquema de versionado por ruta, cadena de consulta o encabezado. Usa versiones para cambios disruptivos (breaking changes); cada versión es una entidad de API separada asociada al mismo conjunto de versiones. Los cambios iterativos y no disruptivos se implementan como revisiones. Una revisión es una instantánea mutable de una API que puede ser invocada explícitamente (a través del sufijo de revisión) para pruebas, mientras que una revisión anterior permanece como la revisión de producción actual. Tras la validación, se promueve la nueva revisión a “actual” sin cambiar el identificador de la versión. Esta separación permite una entrega progresiva y segura: revisiones para actualizaciones no disruptivas; versiones para cambios disruptivos, expuestas a través de un descubrimiento y documentación claros en el portal para desarrolladores.

Finalmente, observa y gobierna. Habilita el rastreo (tracing), establece ID de correlación y exporta diagnósticos a Application Insights para obtener visibilidad de extremo a extremo. Gestiona la configuración a través de ARM/Bicep o el APIM DevOps Resource Kit para lograr despliegues repetibles, y aplica RBAC en el plano de administración para separar las responsabilidades de los autores, publicadores y operadores de API.

Escenario de un problema práctico

Starbucks debe exponer una API pública unificada para pedidos desde móviles que agregue microservicios distribuidos en dos regiones de Azure. La API debe bloquear el acceso anónimo, limitar a los clientes abusivos (throttling), proteger los backends regionales de fallos en cascada y permitir el despliegue gradual de un esquema de pedidos v2 sin afectar a los clientes de la v1.

Desplegar una instancia de APIM Premium en dos regiones y habilitar el despliegue multirregional. Se elige el nivel Premium por su presencia de puerta de enlace (gateway) multirregional, capacidades de red avanzadas y escala empresarial. Las puertas de enlace regionales reducen la latencia para los clientes móviles y proporcionan resiliencia activo-activo.
Importar los servicios de backend como entidades de backend de APIM, incluyendo las instancias de App Service en ambas regiones. Las entidades de backend centralizan las URL base, la configuración de TLS y las credenciales, permitiendo directivas de enrutamiento limpias y portabilidad entre entornos.
Asegurar la comunicación cliente-gateway con Azure AD OAuth 2.0 y validar los tokens usando validate-jwt en la sección de entrada (inbound). Azure AD proporciona identidad centralizada, acceso condicional y una validación de tokens robusta. validate-jwt asegura que solo los llamadores autenticados con las audiencias/ámbitos (audiences/scopes) correctos puedan invocar la API.
Requerir suscripciones a productos y emitir claves de suscripción por cada aplicación de socio. Esto añade una capa de gobernanza y medición independiente de OAuth y permite cuotas por socio, rotación de claves sencilla y auto-registro (onboarding) a través del portal.
Configurar rate-limit-by-key y quota-by-key en la sección de entrada, usando la clave de suscripción como identificador. La limitación de velocidad (throttling) protege los backends de picos de tráfico y permite diferenciar los SLA para los socios. Usar las claves de suscripción como discriminador alinea la aplicación de las políticas con los contratos comerciales.
Implementar filtrado de IP para bloquear rangos maliciosos conocidos y permitir los rangos corporativos propiedad de Starbucks para la administración. La directiva ip-filter reduce la superficie de ataque en una fase temprana del proceso y ahorra recursos en los sistemas posteriores.
Configurar TLS mutuo (mTLS) en el backend para servicios sensibles, subiendo certificados de cliente a APIM y vinculándolos a las entidades de backend correspondientes. mTLS proporciona una autenticación robusta de servicio a servicio cuando los backends requieren certificados, cumpliendo con las políticas de seguridad internas.
Añadir authentication-managed-identity en la sección de backend para los servicios protegidos con Azure AD. La identidad administrada de APIM adquiere tokens de acceso para el backend, eliminando la necesidad de secretos e integrándose con Azure RBAC y el acceso condicional.
Implementar un disyuntor (circuit-breaker) con reintentos y una respuesta de respaldo (fallback) en la sección de backend. Ante fallos repetidos en una ventana de tiempo, abrir el circuito y enrutar las solicitudes al backend regional saludable; si ambos están caídos, devolver una respuesta de respaldo estandarizada y almacenada en caché. Esto protege los servicios degradados y ofrece un comportamiento predecible en caso de fallo.
Usar enrutamiento condicional para balancear las lecturas de carga a la región más cercana y realizar la conmutación por error (failover) basándose en señales de salud. Las expresiones de directiva seleccionan la región local inspeccionando un encabezado personalizado o la geolocalización por IP; las sondas de salud (health probes) rellenan variables para las decisiones de enrutamiento. Esto proporciona baja latencia y continuidad durante incidentes regionales.
Introducir un conjunto de versiones (version set) para la API de Pedidos con versionado basado en ruta (/v1, /v2). Crear una nueva revisión de la v2 para pruebas, validarla con clientes seleccionados invocando la URL específica de la revisión y luego promoverla a “actual”. Los conjuntos de versiones comunican los cambios disruptivos de forma clara, mientras que las revisiones permiten una iteración segura y no disruptiva.
Habilitar el almacenamiento en caché de respuestas para los puntos de conexión con mucha lectura (menú/catálogo) en la sección de salida (outbound) con cache-lookup y cache-store, variando por configuración regional (locale) y tipo de dispositivo. El almacenamiento en caché descarga a los backends de peticiones repetidas y mejora el rendimiento móvil; el nivel Premium soporta estas características a escala.

Este diseño ofrece API autenticadas, limitadas, resilientes y evolutivas. APIM Premium proporciona la puerta de enlace (gateway) global y segura; las directivas aplican la identidad, la limitación de velocidad, la transformación y la resiliencia; las entidades de backend y las identidades administradas aseguran y desacoplan las conexiones; los conjuntos de versiones y las revisiones proporcionan un ciclo de vida disciplinado para la entrega continua sin interrumpir a los clientes.

← Autenticación · Todos los dominios · Soluciones de mensajería y basadas en eventos de Azure →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →