Lecciones en español / AI-200 / Hoja de repaso · English

Hoja de repaso de AI-200 AI-200 (replaced AZ-204)

Cada consejo para el examen y término clave de las lecciones gratuitas de AI-200, por dominio. Usa la opción Imprimir de tu navegador para guardarla como PDF.

Dominio 1: Develop containerized solutions on Azure (24%)

Consejos para el examen

Si una pregunta te pide cómo mantener compiladores o secretos fuera de la imagen final, la respuesta es una compilación multietapa; si te pide cómo evitar que ciertos archivos se envíen siquiera a la compilación, la respuesta es .dockerignore.
Cualquier requisito que mencione varias regiones con un solo nombre de registro, private endpoints o bloquear el acceso público apunta a Premium; Basic y Standard se diferencian sobre todo en almacenamiento y rendimiento.
Relaciona el trigger con la redacción: código subido significa trigger de commit; parches del sistema operativo o del runtime en la imagen padre significan trigger de actualización de la imagen base; y cada noche o cada semana significa trigger de temporizador con una programación cron.
Para una pregunta sobre asegurar que cada réplica ejecute exactamente la misma imagen, elige una etiqueta única o un digest, nunca latest; para la limpieza automática de imágenes antiguas, elige acr purge en una tarea de ACR programada.
Cuando te pregunten por la forma más segura o de mínimo privilegio para que una app descargue imágenes, responde identidad administrada más AcrPull; descarta las opciones que habilitan el usuario administrador o guardan una contraseña.
Si un contenedor personalizado se inicia pero App Service informa que no responde en el puerto esperado, la solución es la configuración de app WEBSITES_PORT, no un cambio de EXPOSE en el Dockerfile.
Los servicios de back end a los que solo deben llamar otras apps del entorno usan ingress interno; los workers que solo procesan colas no necesitan ingress. Recuerda también que actualizar un secreto no reinicia las réplicas por sí solo.
Los escenarios de división del tráfico, blue-green y canary requieren el modo de revisión múltiple; cambiar un secreto o una configuración de ingress nunca crea una nueva revisión, porque tienen alcance de aplicación.
Si un escenario exige escalar a cero, descarta las reglas de escalado por CPU y memoria; usa una regla HTTP para tráfico web o una regla de eventos de KEDA como azure-servicebus para workers de colas, con el mínimo de réplicas en 0.
El trabajo que se ejecuta hasta terminar apunta a Container Apps jobs: elige Manual para bajo demanda, Schedule para horarios basados en cron (UTC) y Event para trabajo impulsado por colas que maneja KEDA.
Los requests determinan la programación y los limits imponen topes (la memoria por encima del límite provoca OOMKilled, la CPU se limita); el acceso a ACR para AKS es az aks update --attach-acr, no una contraseña de administrador en un imagePullSecret.

Términos clave

Base image (imagen base): La imagen indicada en FROM sobre la que se construye tu imagen, como una imagen slim de Python.
Multi-stage build (compilación multietapa): Un Dockerfile con varias etapas FROM en el que la etapa final copia solo los artefactos necesarios de las etapas anteriores.
Build context (contexto de compilación): El conjunto de archivos que se envía al builder con una compilación; .dockerignore quita archivos de él.
Layer cache (caché de capas): La reutilización que hace Docker de los resultados de instrucciones sin cambios, lo que hace que el orden de las instrucciones importe para la velocidad de compilación.
USER instruction (instrucción USER): Define el usuario que usan las instrucciones posteriores y el contenedor en ejecución, para que la app no tenga que ejecutarse como root.
Login server (servidor de inicio de sesión): El nombre DNS del registro, como myregistry.azurecr.io, que se usa como prefijo de cada referencia de imagen.
Geo-replication (replicación geográfica): Una función de ACR Premium que mantiene copias de un registro en varias regiones detrás de un único login server.
Private endpoint (punto de conexión privado): Una interfaz de red con una IP privada en tu VNet que se conecta de forma privada a un servicio, como un registro Premium.
Repository (repositorio): Una colección con nombre de imágenes relacionadas en un registro, que se distinguen por etiquetas y digests.
Quick task (tarea rápida): Una compilación puntual en la nube iniciada con az acr build que sube el contexto, compila en ACR y sube la imagen.
ACR task (tarea de ACR): Una definición de compilación guardada en un registro que se ejecuta automáticamente con triggers como commits, actualizaciones de la imagen base o una programación.
Base image update trigger (trigger de actualización de la imagen base): Un trigger de ACR Tasks que recompila la imagen de tu app cuando se actualiza la imagen de su línea FROM.
Run ID (ID de ejecución): El identificador único de cada ejecución de ACR Tasks, disponible como el marcador {{.Run.ID}} para etiquetas únicas.
Tag (etiqueta): Un rótulo mutable y legible que apunta a un manifiesto de imagen y se puede mover a una imagen más reciente.
Digest: Un identificador SHA-256 inmutable de un manifiesto de imagen que siempre se refiere exactamente al mismo contenido.
Unique tag (etiqueta única): Una etiqueta que se usa una sola vez y nunca se reasigna, como un ID de compilación o un hash de commit; se recomienda para despliegues.
Untagged manifest (manifiesto sin etiqueta): Una imagen cuyas etiquetas se movieron o se quitaron todas; sigue consumiendo almacenamiento hasta que se elimina.
acr purge: Un comando de ACR Tasks que elimina etiquetas y manifiestos sin etiqueta según un filtro y una antigüedad; suele ejecutarse de forma programada.
Admin user (usuario administrador): Una cuenta para todo el registro con contraseñas compartidas y derechos completos de push/pull; está deshabilitada de forma predeterminada y solo está pensada para pruebas.
AcrPull: Un rol integrado de Azure RBAC que concede permiso para descargar imágenes de un registro y nada más.
AcrPush: Un rol integrado que permite tanto subir como descargar imágenes, adecuado para pipelines de compilación.
Managed identity (identidad administrada): Una identidad de Microsoft Entra para un recurso de Azure cuyas credenciales Azure administra y rota automáticamente.
WEBSITES_PORT: Una configuración de app de App Service que le indica a la plataforma en qué puerto escucha el contenedor personalizado.
Continuous deployment (implementación continua, contenedores): Una configuración que hace que App Service descargue la imagen y se reinicie cuando un webhook del registro informa de una imagen nueva para la etiqueta configurada.
Deployment slot (ranura de implementación): Una instancia activa separada de una app, con su propio nombre de host, que se puede intercambiar con producción.
Slot setting (configuración de ranura): Una configuración de app o cadena de conexión marcada como fija para que se quede con su ranura durante un swap.
Container Apps environment (entorno de Container Apps): Un límite que agrupa container apps que comparten una red virtual y un área de trabajo de Log Analytics.
External ingress (ingress externo): Ingress que expone la app fuera del entorno, normalmente con un punto de conexión público.
Internal ingress (ingress interno): Ingress que hace que la app solo sea accesible desde dentro de su entorno.
secretref: El prefijo que se usa en una variable de entorno de una container app para tomar su valor de un secreto a nivel de app.
Revision (revisión): Una instantánea inmutable de la configuración con alcance de revisión de una container app, que se crea cada vez que cambia la plantilla.
Single revision mode (modo de revisión única): El modo predeterminado en el que hay una sola revisión activa y una nueva revisión reemplaza a la anterior en cuanto está lista.
Multiple revision mode (modo de revisión múltiple): Un modo que mantiene varias revisiones activas y reparte el tráfico de ingress entre ellas por peso.
Revision label (etiqueta de revisión): Un puntero con nombre a una revisión que le da una URL estable independiente de su nombre generado.
Replica (réplica): Una instancia en ejecución de una revisión de una container app; el escalado cambia el número de réplicas.
KEDA: Kubernetes Event-driven Autoscaling, el motor de código abierto detrás de las reglas de escalado de Container Apps.
Scale to zero (escalado a cero): Ejecutar cero réplicas cuando no hay actividad; es posible con un mínimo de 0 y reglas HTTP o controladas por eventos.
Scaler: Un componente de KEDA que lee una métrica de un origen de eventos, como el número de mensajes de Service Bus, para impulsar el escalado.
Container Apps job: Un recurso de Container Apps que ejecuta contenedores hasta que terminan, en lugar de hacerlo de forma continua.
Execution (ejecución): Una sola ejecución de un job, que contiene una o más réplicas que deben terminar correctamente.
Trigger type (tipo de desencadenador): Cómo se inicia un job: Manual, Schedule (cron) o Event (reglas de escalado de KEDA).
Replica timeout (tiempo de espera de réplica): El número máximo de segundos que puede ejecutarse una réplica de un job antes de detenerse y considerarse fallida.
Deployment: Un objeto de Kubernetes que mantiene en ejecución un número especificado de pods idénticos y administra las actualizaciones graduales.
Service: Un objeto de Kubernetes que le da a un conjunto de pods, seleccionados por etiquetas, una IP estable, un nombre DNS y equilibrio de carga.
Requests and limits (solicitudes y límites): Configuración de CPU y memoria por contenedor: los requests se reservan para la programación y los limits ponen un tope al uso.
ConfigMap: Un objeto de Kubernetes que almacena datos de configuración no secretos para los pods.
Kubernetes Secret (secreto de Kubernetes): Un objeto para datos sensibles que está codificado en base64, sin que esa codificación lo cifre, y cuyo acceso debe controlarse.

Dominio 2: Develop AI solutions by using Azure data management services (28%)

Consejos para el examen

read_item siempre necesita el id del elemento y la clave de partición; create_item falla con duplicados mientras que upsert_item no, y las consultas entre particiones necesitan enable_cross_partition_query=True.
La clave de partición ganadora tiene alta cardinalidad, una distribución uniforme de solicitudes y almacenamiento, y aparece en la mayoría de las consultas; cuando un inquilino supera los 20 GB, piensa en claves de partición jerárquicas.
Las lecturas en Strong y Bounded Staleness cuestan aproximadamente el doble; excluir rutas no usadas reduce las RU de escritura; una lectura puntual supera a cualquier consulta. Los clientes pueden relajar la coherencia por solicitud, pero no pueden hacerla más fuerte que el valor predeterminado de la cuenta.
Las dimensiones de la directiva vectorial deben coincidir con la salida del modelo de embeddings; elige flat para búsquedas exactas pequeñas, quantizedFlat para tamaño medio y diskANN para gran escala, y excluye la ruta del vector del índice normal.
Las eliminaciones son invisibles en el modo latest version; responde con soft delete más TTL, o con el modo all versions and deletes (que necesita copia de seguridad continua). Dos funciones sobre un mismo contenedor necesitan prefijos de lease o contenedores separados.
Dos pasos en orden: agrega VECTOR al parámetro de servidor azure.extensions y luego ejecuta CREATE EXTENSION vector en cada base de datos; el nombre SQL de la extensión es vector, no pgvector.
Haz coincidir el operador con la clase de operador (<-> con vector_l2_ops, <=> con vector_cosine_ops, <#> con vector_ip_ops). Construye IVFFlat después de cargar los datos; HNSW funciona en tablas vacías. ef_search y probes intercambian velocidad por recall.
Usa el mismo modelo de embeddings para los fragmentos y para las consultas; aplica el control de acceso con filtros de metadatos al recuperar, no pidiéndole al modelo que ignore documentos.
Conoce los nombres de las directivas: allkeys-* expulsa de entre todas las claves, volatile-* solo de las claves con TTL y noeviction devuelve errores en las escrituras cuando la memoria está llena.
La caché semántica coincide por significado, no por texto exacto, así que el equilibrio que evalúa el examen es el umbral de similitud; delimita siempre las entradas de caché (inquilino, modelo, idioma) y asígnales un TTL.
Elige según el requisito dominante: escala global o change feed significa Cosmos DB; joins relacionales o un PostgreSQL existente significa pgvector; latencia mínima o caché de respuestas significa Redis; las combinaciones son comunes y a menudo correctas.

Términos clave

CosmosClient: El punto de entrada de azure-cosmos que se conecta a una cuenta; crea uno y reutilízalo durante toda la vida de la app.
Upsert: Una operación que inserta un elemento si no existe o lo reemplaza si ya existe.
Point read (lectura puntual): Leer un elemento por id y clave de partición con read_item; es la operación más barata de Cosmos DB.
Parameterized query (consulta parametrizada): Una consulta cuyos valores se pasan por separado como parámetros @nombre en lugar de concatenar cadenas.
Logical partition (partición lógica): Todos los elementos que comparten un valor de clave de partición; está limitada a 20 GB de almacenamiento.
Physical partition (partición física): Una unidad interna de almacenamiento y rendimiento que aloja muchas particiones lógicas.
Hot partition (partición caliente): Una partición que recibe una parte desproporcionada de las solicitudes, lo que provoca limitación con 429 pese a que sobra rendimiento total.
Hierarchical partition key (clave de partición jerárquica): Una clave de partición de hasta tres niveles, como inquilino y luego usuario, que permite que un valor de nivel superior abarque varias particiones físicas.
Request Unit (RU, unidad de solicitud): La unidad de costo normalizada para las operaciones de Cosmos DB; una lectura puntual de 1 KB cuesta alrededor de 1 RU.
Indexing policy (directiva de indexación): Configuración del contenedor que elige qué rutas se indexan, el modo de indexación y los índices compuestos o vectoriales.
Session consistency (coherencia de sesión): El nivel predeterminado, que garantiza que un cliente lea sus propias escrituras dentro de su sesión.
HTTP 429: El estado que se devuelve cuando las solicitudes superan el rendimiento aprovisionado; los clientes deben reintentar después del retraso indicado.
Vector embedding policy (directiva de embeddings vectoriales): Configuración del contenedor que define la ruta, el tipo de datos, el número de dimensiones y la función de distancia de cada vector.
flat index (índice flat): Un índice vectorial exacto por fuerza bruta con recall perfecto, adecuado para conjuntos de datos pequeños y dimensiones limitadas.
quantizedFlat index (índice quantizedFlat): Un índice vectorial que comprime los vectores y los recorre, reduciendo el costo con una pequeña pérdida de precisión.
diskANN index (índice diskANN): Un índice de vecinos más cercanos aproximados basado en grafos, diseñado para baja latencia a gran escala.
VectorDistance(): La función de consulta de Cosmos DB que devuelve la puntuación de similitud entre dos vectores.
Change feed (fuente de cambios): Un registro ordenado y persistente de las creaciones y actualizaciones (y, en un modo, las eliminaciones) de un contenedor de Cosmos DB.
Lease container (contenedor de leases): Un contenedor que almacena los puntos de control del change feed y la propiedad de las particiones para los processors y los triggers de Functions.
Latest version mode (modo latest version): El modo predeterminado del change feed, que devuelve el estado más reciente de los elementos modificados y no incluye eliminaciones.
All versions and deletes mode (modo all versions and deletes): Un modo del change feed que registra cada cambio, incluidas las eliminaciones, y requiere copia de seguridad continua.
Flexible server (servidor flexible): La opción de implementación de Azure Database for PostgreSQL que ofrece PostgreSQL administrado con proceso, alta disponibilidad y redes configurables.
azure.extensions: El parámetro de servidor que define la lista de extensiones permitidas que se pueden crear en un flexible server.
pgvector: Una extensión de código abierto de PostgreSQL, creada como vector, que agrega un tipo vector, operadores de distancia e índices ANN.
azure_pg_admin: Un rol de flexible server cuyos miembros pueden realizar acciones administrativas, como crear extensiones permitidas.
vector(n): El tipo de columna de pgvector que guarda un embedding de exactamente n dimensiones.
<=> operator (operador <=>): El operador de distancia coseno de pgvector; los valores más pequeños indican vectores más similares.
HNSW: Un índice ANN basado en grafos con buen recall y velocidad, que se ajusta con m, ef_construction y hnsw.ef_search.
IVFFlat: Un índice ANN basado en clústeres que se construye después de cargar los datos; se ajusta con lists al construirlo y con ivfflat.probes al consultar.
Operator class (clase de operador): La configuración del índice, como vector_cosine_ops, que debe coincidir con el operador de distancia usado en las consultas.
RAG (generación aumentada por recuperación): Retrieval-augmented generation: recuperar datos relevantes en el momento de la consulta y agregarlos al prompt del modelo para fundamentar las respuestas.
Chunking (fragmentación): Dividir los documentos de origen en pasajes, a menudo con superposición, antes de generar sus embeddings.
Top-k retrieval (recuperación top-k): Devolver los k elementos cuyos vectores son más similares al vector de la consulta.
Metadata filter (filtro de metadatos): Una condición sobre propiedades del fragmento, como el inquilino o el idioma, que se aplica junto con la búsqueda vectorial.
Grounding (fundamentación): Limitar la respuesta de un modelo al contenido de origen proporcionado, a menudo con instrucciones y citas.
Cache-aside: Un patrón en el que la app revisa la caché, carga desde la base de datos cuando hay un fallo y llena la caché por sí misma.
TTL (tiempo de vida): Time to live: el número de segundos que existe una clave antes de que Redis la expire automáticamente.
Invalidation (invalidación): Eliminar o actualizar una entrada de caché cuando cambian los datos subyacentes.
Eviction policy (directiva de expulsión): La regla que sigue Redis para liberar memoria cuando está llena, como allkeys-lru o volatile-lru.
FT.CREATE: El comando de búsqueda de Redis que define un índice sobre claves de hash o JSON, incluidos los campos vectoriales.
KNN query (consulta KNN): Una consulta de búsqueda de Redis que devuelve los K vectores más cercanos a un vector de consulta proporcionado.
Semantic cache (caché semántica): Una caché que devuelve respuestas del modelo almacenadas para prompts cuyos embeddings son lo bastante similares al prompt nuevo.
Similarity threshold (umbral de similitud): La distancia máxima a la que un prompt en caché se considera una coincidencia en una caché semántica.
System of record (sistema de registro): El almacén autoritativo y duradero de los datos, a diferencia de una caché que se puede reconstruir.
Operational data (datos operativos): Los datos activos de la aplicación, como pedidos o perfiles, junto a los cuales se pueden almacenar los vectores.
Global distribution (distribución global): Replicar una base de datos en varias regiones para lecturas y escrituras locales, una característica central de Cosmos DB.
In-memory store (almacén en memoria): Un almacén de datos como Redis que guarda los datos en RAM para lograr una latencia muy baja a un costo mayor por gigabyte.

Dominio 3: Connect to and consume Azure services (24%)

Consejos para el examen

Un consumidor por mensaje significa una cola; que cada consumidor reciba una copia significa un tema con suscripciones, lo que requiere Standard o Premium porque Basic no tiene temas.
Si los mensajes no deben perderse, usa peek-lock; los errores de bloqueo perdido en trabajos largos significan renovar el bloqueo (AutoLockRenewer) o subir la duración del bloqueo hasta cinco minutos; abandon incrementa el contador de entregas.
Los mensajes expirados se descartan, no se envían a mensajes fallidos, a menos que esté habilitado el envío a mensajes fallidos al expirar; los mensajes dañinos llegan a la DLQ después de superar el max delivery count (10 de forma predeterminada).
FIFO por cliente o por pedido significa sesiones; los envíos reintentados que crean duplicados significan detección de duplicados con IDs de mensaje de negocio; para enrutar por valores exactos de propiedades, prefiere los filtros de correlación sobre los filtros SQL.
Los servicios de Azure emiten a temas del sistema; tu código publica en temas personalizados. Para filtrar por contenedor o carpeta usa "subject begins with"; para filtrar por extensión de archivo usa "subject ends with".
Valores predeterminados que debes recordar: 30 intentos de entrega y 1,440 minutos de TTL; los eventos no entregados se descartan a menos que se configure el envío a mensajes fallidos en Blob Storage. Un webhook personalizado debe devolver el validationCode como validationResponse (o llamar a validationUrl).
Asocia palabras clave: mensajes de negocio garantizados, ordenados y transaccionales significan Service Bus; reaccionar a eventos de recursos de Azure o eventos discretos significa Event Grid; flujos de telemetría de gran volumen con reproducción significan Event Hubs.
En el modelo v2, los decoradores de function_app.py reemplazan a function.json; el parámetro connection nombra una configuración de la app, no una cadena de conexión literal, y cada función tiene un trigger pero cualquier número de enlaces.
Las programaciones del timer tienen seis campos, con los segundos primero (0 */5 * * * * es cada cinco minutos). La autorización FUNCTION necesita una clave en x-functions-key o en code; no es autenticación de usuarios.
Cero arranques en frío más escalado elástico apunta a Premium (o a Flex con instancias siempre listas); si ya pagas un App Service plan, apunta a Dedicated con Always On; el acceso a redes privadas necesita un plan con integración con VNet.
local.settings.json es solo local y no se implementa; host.json es la configuración del runtime para toda la app y sí se implementa; las conexiones basadas en identidad usan configuraciones con doble guion bajo, como __fullyQualifiedNamespace, más un rol de RBAC.

Términos clave

Namespace (espacio de nombres): El recurso contenedor de Service Bus que aloja colas y temas y define el nivel.
Queue (cola): Una entidad punto a punto en la que cada mensaje lo recibe exactamente un consumidor.
Topic (tema): Una entidad de publicación-suscripción en la que cada suscripción que coincide recibe su propia copia de un mensaje.
Subscription (suscripción): Una vista con nombre, similar a una cola, de un tema, con sus propias reglas de filtro y receptores.
Competing consumers (consumidores en competencia): Varios receptores que leen de la misma cola para repartirse el trabajo.
Peek-lock (inspeccionar y bloquear): El modo de recepción predeterminado que bloquea un mensaje hasta que el receptor lo completa, abandona, difiere o envía a mensajes fallidos.
Receive-and-delete (recibir y eliminar): Un modo de recepción que elimina el mensaje al entregarlo, lo que da procesamiento como máximo una vez.
Lock duration (duración del bloqueo): Cuánto tiempo permanece un mensaje recibido bloqueado para un receptor antes de volver a ser visible; un minuto de forma predeterminada, cinco como máximo.
Defer (diferir): Liquidar un mensaje de modo que permanezca en la cola, pero solo pueda recibirse de nuevo por su número de secuencia.
AutoLockRenewer: Una utilidad del SDK de Python que renueva los bloqueos de mensajes en segundo plano durante un procesamiento largo.
Dead-letter queue (cola de mensajes fallidos): Una subcola integrada de cada cola o suscripción que guarda los mensajes que no se pudieron entregar ni procesar.
Max delivery count (número máximo de entregas): El número de intentos de entrega tras el cual Service Bus envía automáticamente un mensaje a mensajes fallidos; 10 de forma predeterminada.
Poison message (mensaje dañino): Un mensaje que falla en el procesamiento cada vez y que daría vueltas para siempre sin el envío a mensajes fallidos.
Dead-lettering on expiration (envío a mensajes fallidos al expirar): Una configuración de la entidad, desactivada de forma predeterminada, que mueve los mensajes expirados a la DLQ en lugar de descartarlos.
Session (sesión): Un grupo de mensajes que comparten un ID de sesión y que Service Bus entrega en orden a un receptor a la vez.
Duplicate detection (detección de duplicados): Una configuración de cola o tema que descarta los mensajes cuyo ID de mensaje ya se vio dentro de una ventana de historial.
Scheduled message (mensaje programado): Un mensaje que se acepta de inmediato, pero que queda disponible para los receptores solo a una hora UTC especificada.
SQL filter (filtro SQL): Una regla de suscripción que usa una expresión similar a SQL sobre las propiedades del mensaje.
Correlation filter (filtro de correlación): Una regla de suscripción que coincide con valores exactos de propiedades del sistema o de usuario, más económica que un filtro SQL.
System topic (tema del sistema): Un tema de Event Grid que representa los eventos publicados automáticamente por un servicio de Azure.
Custom topic (tema personalizado): Un tema de Event Grid que creas y en el que publicas los eventos de tu propia aplicación.
Event subscription (suscripción a eventos): La configuración que vincula un tema con un controlador, con filtros que deciden qué eventos se entregan.
Subject filter (filtro de asunto): Un filtro que coincide con el inicio o el final de la ruta del asunto de un evento, como un contenedor o una extensión de archivo.
Advanced filter (filtro avanzado): Un filtro sobre campos de los datos o del sobre del evento que usa operadores como NumberGreaterThan o StringContains.
Retry policy (directiva de reintentos): Límites por suscripción de intentos de entrega y de tiempo de vida del evento que rigen los reintentos de Event Grid.
Event time-to-live (tiempo de vida del evento): El número de minutos que Event Grid sigue reintentando un evento antes de rendirse; 1,440 de forma predeterminada.
Dead-letter destination (destino de mensajes fallidos): Un contenedor de Blob Storage donde Event Grid escribe los eventos que no pudo entregar.
Validation handshake (protocolo de validación): El proceso mediante el cual un webhook demuestra que es propietario del punto de conexión antes de que Event Grid le entregue eventos.
CloudEvents: Una especificación abierta para describir los datos de eventos en un formato común entre servicios y nubes.
Discrete event (evento discreto): Un evento que informa de un único cambio de estado con significado propio, muy adecuado para Event Grid.
Event stream (flujo de eventos): Una secuencia continua de eventos, como la telemetría, que se analiza en conjunto y es adecuada para Event Hubs.
Consumer group (grupo de consumidores): Una vista independiente de un flujo de Event Hubs que permite que varias aplicaciones lo lean cada una desde su propia posición.
Load leveling (nivelación de carga): Usar una cola para absorber ráfagas y que los workers procesen a un ritmo constante, un punto fuerte de Service Bus.
Trigger (desencadenador): El evento que inicia una función; cada función tiene exactamente uno.
Binding (enlace): Una conexión declarativa con otro servicio que proporciona datos de entrada o escribe la salida sin código del SDK.
function_app.py: El archivo de entrada de una function app de Python v2 que crea FunctionApp y define las funciones decoradas.
func.Out: El tipo de parámetro de un enlace de salida; llamar a set() proporciona el valor que se va a escribir.
Blueprint: Una característica del modelo v2 para definir funciones en módulos separados y registrarlas en la app.
Authorization level (nivel de autorización): Configuración del trigger HTTP (anonymous, function o admin) que decide qué clave, si la hay, debe proporcionar quien llama.
NCRONTAB: El formato cron de seis campos que usan los triggers de temporizador, que empieza con un campo de segundos.
Past due (atrasado): Un indicador del temporizador que señala que la ejecución programada ocurrió más tarde de lo previsto, por ejemplo después de una interrupción.
Event Grid-based blob trigger (trigger de blob basado en Event Grid): Un trigger de blob que usa notificaciones de Event Grid en lugar de sondeo para lograr menor latencia.
Flex Consumption: Un plan serverless de Functions en Linux con escalado a cero controlado por eventos, escalado por función, instancias siempre listas e integración con VNet.
Premium plan (plan Premium): Un plan elástico de Functions con instancias precalentadas, sin arranque en frío para las instancias mínimas y compatible con VNet.
Dedicated plan (plan dedicado): Ejecutar funciones en un App Service plan con escalado manual o automático y costo fijo.
Cold start (arranque en frío): La latencia de inicio cuando se invoca una función y no hay ninguna instancia activa disponible.
Always On: Una configuración de App Service que mantiene cargada una function app del plan Dedicated para que los triggers sigan activándose.
App settings (configuración de la app): Variables de entorno de una function app en Azure, que el código lee y los enlaces referencian.
local.settings.json: Un archivo solo local cuya sección Values carga Core Tools como variables de entorno; no se implementa de forma predeterminada.
host.json: Un archivo de configuración del runtime para toda la app (registro, extensiones, tiempos de espera y muestreo) que se implementa con el código.
Identity-based connection (conexión basada en identidad): Una conexión de enlace definida por configuraciones como Prefijo__fullyQualifiedNamespace que se autentica con una identidad administrada.

Dominio 4: Secure, monitor, and troubleshoot Azure solutions (24%)

Consejos para el examen

Compartida entre recursos o creada antes que el recurso significa asignada por el usuario; ciclo de vida ligado a un solo recurso significa asignada por el sistema. Con una identidad asignada por el usuario, define AZURE_CLIENT_ID para que DefaultAzureCredential elija la correcta.
Contributor u Owner no conceden acceso a los datos; elige el rol de datos que corresponde a la acción (Secrets User para leer secretos, Data Sender o Receiver para Service Bus, AcrPull para imágenes) y recuerda que los roles de datos de Cosmos DB se asignan con az cosmosdb sql role assignment.
Los secretos son valores que lees, las claves hacen criptografía dentro del almacén y los certificados son X.509 con administración del ciclo de vida. La protección contra purga no se puede deshabilitar una vez habilitada; RBAC permite un ámbito por secreto, las directivas de acceso no.
SecretNearExpiry se activa 30 días antes de la expiración y llega a los controladores mediante Event Grid; el proceso de rotación necesita Secrets Officer, los lectores necesitan Secrets User y los consumidores deben hacer referencia al secreto sin versión para obtener los valores nuevos.
Si una app recibe el texto @Microsoft.KeyVault sin procesar, la referencia no se resolvió: revisa la identidad, su rol Secrets User, keyVaultReferenceIdentity para identidades asignadas por el usuario y la red del almacén. Omite la versión para seguir las rotaciones.
Valores específicos por entorno significan etiquetas; activar o desactivar en tiempo de ejecución significa marcas de características; recargar todo de forma coherente significa clave centinela; una configuración que nunca cambia para una versión significa instantáneas. Los secretos se quedan en Key Vault, referenciados desde App Configuration.
Define APPLICATIONINSIGHTS_CONNECTION_STRING y llama a configure_azure_monitor temprano. Recuerda la correspondencia: los spans de servidor van a requests, los spans de cliente a dependencies, la salida de logging a traces y las mediciones del meter a customMetrics.
El ID de traza compartido aparece como operation_Id; el muestreo es por traza y se registra en itemCount, así que cuenta con sum(itemCount); Live Metrics es en tiempo real y no se ve afectado por el muestreo.
Aprende qué contiene cada tabla (requests entrantes, dependencies salientes, exceptions errores, traces registros), usa bin(timestamp, intervalo) dentro de summarize para los gráficos temporales y haz join por operation_Id para correlacionar.
Un umbral sobre una métrica numérica con la detección más rápida significa alerta de métricas; las condiciones que necesitan una consulta, joins o búsqueda de texto significan alerta de búsqueda de registros; las notificaciones y la automatización viven en grupos de acciones reutilizables.
Container Apps: los problemas de inicio, descarga de imágenes, sondas y escalado están en los registros del sistema; los errores de la aplicación están en los registros de consola. Los contenedores de App Service necesitan que se habilite el registro en el sistema de archivos para que el log stream muestre la salida del contenedor.

Términos clave

System-assigned identity (identidad asignada por el sistema): Una identidad administrada ligada al ciclo de vida de un recurso y que se elimina con él.
User-assigned identity (identidad asignada por el usuario): Un recurso de identidad administrada independiente que se puede asociar a muchos recursos y que sobrevive a ellos.
DefaultAzureCredential: Una credencial de azure-identity que prueba en orden el entorno, la workload identity, la identidad administrada y los inicios de sesión de desarrollador.
AZURE_CLIENT_ID: La variable de entorno que le indica a azure-identity qué identidad administrada asignada por el usuario usar.
Data plane (plano de datos): Operaciones sobre los datos dentro de un servicio, como leer secretos o enviar mensajes, a diferencia de administrar el recurso.
Key Vault Secrets User: Un rol integrado que puede leer el contenido de los secretos en un Key Vault con RBAC habilitado.
Azure Service Bus Data Sender: Un rol integrado que permite a una identidad enviar mensajes a las colas y temas de su ámbito.
Cosmos DB Built-in Data Contributor: Un rol de datos nativo de Cosmos DB que permite leer y escribir elementos, asignado mediante asignaciones de roles SQL de Cosmos DB.
Secret (secreto): Un valor confidencial pequeño, como una contraseña o una cadena de conexión, que una app lee de Key Vault.
Key (clave): Una clave criptográfica almacenada en Key Vault que realiza operaciones dentro del almacén sin exponer el material privado.
Soft delete (eliminación temporal): La retención de almacenes y objetos eliminados durante 7 a 90 días para que se puedan recuperar.
Purge protection (protección contra purga): Una configuración que impide la eliminación permanente hasta que termina el periodo de retención; no se puede deshabilitar una vez activada.
Access policy (directiva de acceso): El modelo de autorización heredado de Key Vault que concede permisos por almacén, a diferencia de Azure RBAC.
Secret rotation (rotación de secretos): Reemplazar periódicamente un secreto por un valor nuevo y retirar el anterior para limitar la exposición.
SecretNearExpiry: Un evento de Key Vault publicado mediante Event Grid 30 días antes de la fecha de expiración de un secreto.
SecretNewVersionCreated: Un evento de Key Vault que se genera cuando se crea una versión nueva de un secreto.
Dual-credential rotation (rotación de doble credencial): Alternar entre dos claves válidas para que una pueda regenerarse mientras las apps usan la otra.
Key Vault reference (referencia de Key Vault): Un valor de configuración o secreto de la app que apunta a un secreto de Key Vault, que la plataforma resuelve en tiempo de ejecución.
@Microsoft.KeyVault(...): La sintaxis de referencia que se usa en la configuración de las apps de App Service y Functions, con VaultName/SecretName o SecretUri.
keyVaultReferenceIdentity: La propiedad del sitio de App Service que selecciona una identidad asignada por el usuario para resolver las referencias de Key Vault.
keyvaultref: La sintaxis de secretos de Container Apps que obtiene el valor de un secreto a partir del URI de un secreto de Key Vault con una identidad.
Label (etiqueta): Un valor que distingue versiones de la misma clave, que se usa comúnmente para entornos como Dev y Prod.
Feature flag (marca de característica): Un par clave-valor que activa o desactiva una característica en tiempo de ejecución, opcionalmente con filtros como porcentaje o segmentación.
Sentinel key (clave centinela): Una sola clave vigilada cuyo cambio indica a la app que vuelva a cargar toda su configuración a la vez.
Snapshot (instantánea): Una copia inmutable y con nombre de pares clave-valor seleccionados que siempre devuelve la misma configuración.
Azure Monitor OpenTelemetry Distro: El paquete azure-monitor-opentelemetry que configura OpenTelemetry para enviar la telemetría de Python a Application Insights.
Connection string (cadena de conexión): La configuración que indica adónde va la telemetría, incluida la clave de instrumentación y el punto de conexión de ingesta.
Span: Una unidad de trabajo con tiempo medido dentro de una traza, con atributos, estado y un span padre.
Custom metric (métrica personalizada): Una medición definida por la aplicación, como un contador o un histograma, almacenada en la tabla customMetrics.
Trace context (contexto de traza): El estándar de W3C para propagar los IDs de traza y de span entre servicios, que viaja en el encabezado traceparent.
operation_Id: El campo de Application Insights que contiene el ID de traza compartido por toda la telemetría de una operación.
Sampling (muestreo): Conservar solo una parte de la telemetría, decidido por traza, para reducir costos sin dejar de ser representativo.
Live Metrics (métricas en vivo): Una vista casi en tiempo real de las métricas de solicitudes, errores y recursos que no se ve afectada por el muestreo.
Application map (mapa de aplicación): Una vista de Application Insights que muestra los componentes y sus dependencias con datos de rendimiento y errores.
KQL: Kusto Query Language, el lenguaje de consultas basado en canalizaciones de Log Analytics y Application Insights.
summarize: El operador de KQL que agrega filas en grupos con funciones como count, avg y percentile.
bin(): Una función que redondea valores en intervalos de tamaño fijo, que se usa a menudo con timestamp para construir series temporales.
join: Un operador que combina filas de dos tablas según columnas coincidentes, como operation_Id.
render: Un operador que muestra los resultados de una consulta como un gráfico, por ejemplo un timechart.
Metric alert (alerta de métricas): Una regla de alerta sobre una métrica numérica con umbrales estáticos o dinámicos, que se evalúa con frecuencia y se resuelve automáticamente.
Log search alert (alerta de búsqueda de registros): Una regla de alerta que ejecuta una consulta KQL de forma programada y se activa según los resultados.
Action group (grupo de acciones): Un conjunto reutilizable de notificaciones y acciones automatizadas que activan las reglas de alerta.
Dynamic threshold (umbral dinámico): Una condición de alerta de métricas que aprende el comportamiento normal y se activa ante desviaciones significativas.
Alert processing rule (regla de procesamiento de alertas): Una regla que suprime o agrega acciones a las alertas activadas en un ámbito, por ejemplo durante un mantenimiento.
Log stream (secuencia de registros): Una vista en tiempo real de la salida de registros de una app en el portal o en la CLI.
Console logs (registros de consola): En Container Apps, la salida stdout y stderr de tus contenedores.
System logs (registros del sistema): En Container Apps, los eventos generados por la plataforma, como aprovisionamiento, descargas de imágenes, fallas de sondas y escalado.
Invocations view (vista de invocaciones): La página de supervisión de Functions que enumera las ejecuciones recientes con su estado, duración y registros de Application Insights.

Estudia AI-200 gratis
Plan semana a semana con lecciones, cuestionarios, simulaciones de examen y práctica, en español.

Abrir el plan de estudio