Has construido una plataforma completa, la has mirado de conjunto, la has auditado con un marco reconocido, has catalogado los errores que la habrían hundido y has planificado la migración de lo que quedaba fuera. Queda mirar hacia delante: hacia dónde va Azure, qué conviene vigilar, y cómo acreditar lo que ya sabes hacer.

Esta lección tiene dos mitades muy distintas. La primera repasa las corrientes que están cambiando la plataforma y el oficio, con una advertencia previa e importante: cualquier lista de tendencias caduca. Algunas de las que aparecen aquí serán obviedades dentro de dos años, otras se habrán quedado en promesa, y aparecerán dos o tres que hoy nadie menciona. Por eso lo verdaderamente útil no es la lista, sino el criterio para leerla y el hábito de vigilar los cambios, incluido el trabajo poco glamuroso de saber qué se deja de soportar y cuándo.

La segunda mitad es concreta y sí caduca poco: el mapa de certificaciones de Azure, cuál corresponde a tu perfil, qué te falta realmente para presentarte después de este curso, cómo estudiar, cómo funciona el examen y cómo seguir practicando cuando cierres esta página.

1. Cómo leer una lista de tendencias
2. IA integrada en todo
3. Ingeniería de plataforma
4. Sin servidor y basado en eventos por defecto
5. Nube distribuida y borde
6. Sostenibilidad
7. Seguridad: hacia dónde se mueve
8. FinOps como disciplina consolidada
9. Regulación europea
10. Cómo mantenerse al día sin ahogarse
11. El mapa de certificaciones de Azure
12. Qué certificación te toca
13. Cómo estudiar y cómo es el examen
14. Cómo seguir practicando
15. Errores Comunes y Consejos
16. Ejercicios
17. Conclusión

Tres filtros que conviene aplicar a cualquier novedad, incluida cada una de las que siguen:

Regla práctica: en producción, adopta lo que esté en disponibilidad general y tenga camino de retirada publicado; experimenta con lo demás en -dev y con presupuesto acotado. Y desconfía por sistema de la palabra «revolución»: la mayor parte del progreso en la nube consiste en que algo que ya hacías pasa a requerir menos trabajo.

La corriente más visible. No solo como servicio que se consume —oai-contoso-pro ya está en la plataforma—, sino como capa dentro de las herramientas.

Lo que un equipo de infraestructura debe interiorizar, y es lo menos comentado: un agente es una identidad con permisos. Todo lo aprendido en el módulo 4 —mínimo privilegio, identidades administradas, ámbito acotado, auditoría— aplica igual, con dos agravantes: actúa a velocidad de máquina y su comportamiento no es del todo determinista. Un agente con papel de colaborador sobre una suscripción es exactamente tan peligroso como suena. Añádase el coste, que en IA es por consumo y muy variable, y la conclusión es que las novedades de IA se gobiernan con las herramientas de siempre: presupuesto, cuotas, etiquetas y permisos mínimos.

DevOps resolvió que quien construye también opera. Su límite apareció cuando cada equipo tuvo que aprender redes, seguridad, coste y observabilidad, y la carga cognitiva se volvió insostenible. La respuesta es la ingeniería de plataforma: un equipo que construye una plataforma interna de desarrollo con caminos pavimentados —plantillas, catálogos y autoservicio con barreras— para que los equipos de producto entreguen sin reinventar la infraestructura.

Herramientas a vigilar: Radius, un modelo de aplicación independiente de la nube que describe la aplicación y sus dependencias en lugar de sus recursos; los entornos de despliegue y catálogos de plantillas de Azure; y Backstage en el mundo abierto. La idea de fondo no es nueva ni depende de ninguna herramienta: si el camino correcto no es también el fácil, la gente se lo salta —justo la conclusión del apartado de gobierno de la lección 09-03—.

Para construir algo nuevo, la pregunta por defecto ha dejado de ser «qué tamaño de máquina» y ha pasado a ser «por qué necesitaría un servidor». La progresión que has recorrido en el curso —máquinas virtuales, App Service, Container Apps, Functions— es la del sector entero:

Lo que se generaliza junto con esto es el modelo basado en eventos: componentes pequeños que reaccionan a un mensaje o un evento, con Service Bus y Event Grid como sistema nervioso, exactamente el patrón que separa la venta de la generación de tarjetas en Contoso. Su ventaja es doble —resiliencia y coste—, y su precio también: depurar un sistema distribuido es más difícil, y por eso la traza correlacionada del módulo 7 deja de ser un lujo.

La nube deja de ser un sitio y pasa a ser un modelo de gestión que se extiende a donde estén los sistemas.

Arc merece un comentario porque encaja justo con la lección anterior: permite empezar a gobernar antes de migrar. Los servidores de Barcelona pueden estar inventariados, con directivas evaluadas, con Defender vigilando y con sus registros en log-contoso-pro meses antes de que se muevan; y algunos podrían no moverse nunca y seguir gobernados igual. Convierte la migración de un salto en un proceso gradual.

La eficiencia energética ha pasado de ser un asunto de imagen a ser un requisito de informe: cada vez más organizaciones deben reportar emisiones, y las de sus proveedores de nube cuentan.

• El panel de emisiones de carbono de Azure estima la huella asociada al consumo, por suscripción, servicio y región, con la misma lógica de imputación que Cost Management.
• Las decisiones que la reducen son casi todas decisiones que ya conoces: apagar lo que no se usa, dimensionar bien, escalar a cero, elegir servicios administrados con mayor densidad, archivar datos fríos en niveles adecuados y elegir regiones con mejor mezcla energética.
• Existe un enfoque de ingeniería de software sostenible —eficiencia de código, de datos y de red— que en la práctica coincide con optimizar coste.

La observación práctica: el eje verde y el eje coste apuntan casi siempre en la misma dirección. La optimización del módulo 8, que bajó la factura de Contoso un 29 %, redujo también su huella sin que ese fuera el objetivo. Las excepciones existen —la redundancia geográfica consume más y no se toca—, y ahí vuelve a aplicar la lógica de compromisos del Well-Architected.

Sobre lo poscuántico, sin alarmismo y sin negacionismo: no hay que reescribir nada hoy, pero sí conviene saber dónde se usa criptografía —qué certificados, qué algoritmos, qué protocolos, qué dependencias— porque la migración futura será mucho más barata para quien tenga ese inventario. El riesgo real y presente se llama «recolectar ahora, descifrar después», y afecta sobre todo a datos con vida útil larga.

Lo que en el módulo 8 se presentó como cultura se está profesionalizando: papeles definidos, certificaciones propias, herramientas nativas y una tendencia clara a integrar el coste en el flujo de desarrollo en lugar de auditarlo después. Dos derivadas que conviene conocer: el FinOps para IA, donde el coste por token y las cuotas se comportan de forma distinta a la infraestructura clásica y sorprenden a mucha gente; y la unificación de coste, sostenibilidad y valor de negocio en un mismo panel, que es hacia donde apunta la práctica.

Para cualquier equipo que opere en Europa, la regulación ha dejado de ser un anexo del proyecto y condiciona decisiones de arquitectura desde el primer día.

Cómo se traduce en decisiones concretas: la residencia determina regiones permitidas —una directiva, como la que Contoso ya tiene—; la notificación de incidentes exige detección y trazabilidad reales, no teóricas, con registros conservados y consultables; la resiliencia probada convierte el simulacro semestral en obligación en lugar de en buena práctica; y la estrategia de salida obliga a poder responder a «¿qué haríamos si tuviéramos que dejar este proveedor?».

Advertencia: nada de esto es asesoramiento legal. Los ámbitos de aplicación, plazos y obligaciones tienen matices que dependen del sector, del tamaño y del papel de la organización. El cumplimiento lo determina y valida el equipo legal o de cumplimiento; el equipo técnico aporta capacidades —cifrado, registro, residencia, retención, evidencia— y documenta lo que hace.

El trabajo menos glamuroso y más rentable es el segundo: vigilar las retiradas. Los servicios y versiones se retiran con años de aviso, y aun así pillan a la mitad de las organizaciones —la versión del entorno de ejecución que deja de recibir soporte, la SKU que ya no se ofrece, la característica sustituida—. Una revisión mensual de treinta minutos evita migraciones de urgencia. Y un consejo de higiene informativa: filtra por lo que usas. Intentar seguir Azure entero es imposible y contraproducente; sigue los quince servicios de tu plataforma y olvida el resto hasta que lo necesites.

Las certificaciones no sustituyen a la experiencia, pero estructuran el estudio, acreditan ante terceros y abren procesos de selección. El mapa actual, por niveles:

Orden que tiene sentido, sin ser dogmático: AZ-900 si vienes de cero; después AZ-104 o AZ-204 según tu papel, que son las dos puertas reales; luego una especialización —AZ-500, AZ-700, DP-300, AI-102— o directamente el nivel experto. AZ-305 no se aborda sin experiencia real de diseño: es la certificación que más se suspende por estudiar sin haber tomado decisiones de arquitectura de verdad.

Sé honesto contigo mismo con la última columna. Este curso te ha dado el mapa completo y el criterio, que es lo más difícil de adquirir en solitario; lo que no puede darte es el número de horas de teclado que exige un examen práctico. Con este curso más entre 40 y 80 horas de laboratorio dirigido, AZ-900 es cómodo y AZ-104 o AZ-204 son alcanzables. AZ-305 es otra cosa: pide haber tomado decisiones reales con consecuencias reales.

Recursos, por orden de utilidad real:

1. Microsoft Learn: rutas de aprendizaje gratuitas alineadas con cada examen; es la fuente canónica y la que define el temario.
2. Laboratorios prácticos: los oficiales, y sobre todo tu propia suscripción. Construir es insustituible.
3. Exámenes de práctica: útiles al final, para calibrar formato y ritmo, no para aprender.
4. Documentación oficial: la respuesta a las preguntas difíciles suele estar en los límites y cuotas del servicio.
5. La lista de aptitudes medidas del examen: es el temario literal, con porcentajes por área. Estúdiala como si fuera un índice, porque lo es.

El formato del examen: entre 40 y 60 preguntas, unos 100-120 minutos, con opción múltiple, arrastrar y soltar, ordenar secuencias y casos prácticos —escenarios largos con varias preguntas encadenadas, que es donde se decide el aprobado en los niveles asociado y experto—. Algunas preguntas no se pueden revisar después de contestarlas, así que conviene leer con calma. Se puede hacer en centro o en línea con supervisión, y hay ajustes disponibles para quien los necesite, incluido tiempo extra si el examen no es en tu idioma nativo.

Consejos de examen que marcan diferencia: en los casos prácticos, lee primero las preguntas y después el escenario; descarta las respuestas que violan un principio básico —conceder de más, exponer a internet, romper la residencia—, que suelen ser dos de las cuatro; y cuando dudes entre dos opciones válidas, elige la más gestionada y de menor privilegio, porque es casi siempre la que el examen considera correcta.

Renovación: las certificaciones de nivel asociado y experto caducan al año y se renuevan gratis y en línea, con una evaluación breve sin supervisión, disponible desde seis meses antes del vencimiento. Las de fundamentos no caducan. Es un buen mecanismo: obliga a repasar lo que ha cambiado una vez al año.

Nada de lo anterior sirve sin práctica. Proyectos propios que enseñan de verdad, en orden creciente de ambición:

• Reconstruye una versión mínima de Contoso: una web en App Service con base de datos, secretos en Key Vault, identidad administrada y un pipeline que despliegue. Es el 60 % de este curso en un fin de semana.
• Escribe todo en Bicep y bórralo entero al terminar. Si puedes recrearlo con un comando, lo has entendido.
• Rompe cosas a propósito: apaga una instancia, revoca un permiso, provoca un fallo y observa qué alerta salta y qué traza lo explica.
• Monta la observabilidad antes que la aplicación, aunque sea al revés de lo natural. Cambia la forma de construir.
• Contribuye o publica: una plantilla, un artículo sobre algo que te costó, una charla interna. Explicar consolida como ninguna otra cosa.
• Participa en la comunidad: grupos de usuarios, eventos, foros y los repositorios de ejemplos oficiales.

Advertencia final, y muy en serio: vigila el gasto de tu suscripción de aprendizaje. Es el error más común y más doloroso al empezar. Aplica desde el primer minuto lo que aprendiste en el módulo 8: presupuesto con alerta, etiqueta con fecha de caducidad, apaga o elimina el grupo de recursos entero al terminar cada práctica, evita las SKU caras —firewalls, puertas de enlace, clústeres, instancias reservadas— salvo el rato justo del laboratorio, y revisa la factura cada semana. Un clúster olvidado un mes cuesta más que este curso.

• Perseguir todas las tendencias. Filtra por lo que resuelve un problema que tienes hoy; el resto, en una lista de vigilancia.
• Adoptar vistas previas en producción. Sin compromiso de servicio ni garantía de continuidad; en -dev sí, y con presupuesto acotado.
• Ignorar las fechas de retirada. Es el trabajo aburrido que evita las migraciones de urgencia.
• Coleccionar certificaciones sin construir nada. Se nota en la primera entrevista técnica y, peor, en el primer incidente.
• Estudiar solo con volcados de preguntas. Además de estar prohibido y poder invalidar la certificación, no enseña a resolver un caso práctico.
• Presentarse a AZ-305 sin experiencia de diseño. Es la vía más rápida a un suspenso caro.
• Olvidar la renovación anual. Es gratuita, breve y en línea; dejar caducar una certificación por descuido es una pena evitable.
• Dejar la suscripción de prácticas encendida. El recibo llega igual aunque el laboratorio se abandonara hace tres semanas.
• Consejo: dedica media hora al mes a Azure Updates filtrado por tus servicios y a las retiradas anunciadas. Es la mejor relación entre tiempo invertido y sustos evitados.
• Consejo: elige una certificación, ponle fecha de examen y resérvalo. Sin fecha, el estudio se diluye.
• Consejo: mantén un cuaderno de decisiones propio, como la tabla de decisiones de 09-01. Dentro de dos años será tu activo más valioso.

Ejercicio 1. Selecciona tres de las tendencias de esta lección y evalúalas para la plataforma de Contoso Airlines con los tres filtros del apartado 1: qué problema real resolvería, en qué estado de madurez la adoptarías y cuál sería el coste de equivocarse. Termina proponiendo cuál adoptarías este año, cuál pondrías en vigilancia y cuál descartarías, con su justificación.

Ejercicio 2. Diseña tu propio plan de certificación y estudio para los próximos doce meses: parte de tu perfil real y del punto en que estás, elige la certificación objetivo y la siguiente, define hitos trimestrales, cuantifica las horas semanales que puedes dedicar de verdad, e identifica las tres carencias concretas que este curso no te ha cubierto para ese examen y cómo las vas a cubrir.

Ejercicio 3. Una aerolínea competidora anuncia que aplicará IA generativa a la atención al pasajero, incluyendo cambios de reserva conversacionales. Contoso se plantea lo mismo. Analiza la propuesta desde las cinco perspectivas del curso: arquitectura —qué piezas existentes se reutilizan y cuáles faltan—, seguridad e identidad —qué permisos tendría el agente y cómo se acotan—, coste —qué modelo de gasto tiene y cómo se controla—, operación —cómo se supervisa y qué se registra— y regulación —qué obligaciones aparecen y quién las valida—. Concluye con una recomendación: sí, no, o sí con condiciones.

Solución 1: una selección razonable. Azure Arc. Problema real: Contoso tiene 34 servidores en Barcelona sin gobierno homogéneo y una migración de 18 meses por delante; Arc permite aplicar directivas, Defender y supervisión centralizada antes de mover nada, y reduce el riesgo de la migración porque el inventario y la telemetría llegan antes que el traslado. Madurez: consolidada y con disponibilidad general. Coste de equivocarse: bajo —se instala un agente, se puede revertir— aunque tiene coste por servidor en algunas capacidades. Veredicto: adoptar este año, es la que mejor encaja con el proyecto en curso. IA en la operación y agentes. Problema real: el equipo dedica tiempo a correlacionar incidentes y escribir KQL; hay ganancia clara, pero no resuelve ningún problema crítico y la plataforma ya tiene observabilidad sana. Madurez: en evolución rápida, con capacidades que cambian de trimestre en trimestre. Coste de equivocarse: medio —consumo variable, y sobre todo el riesgo de conceder permisos amplios a software autónomo—. Veredicto: vigilancia y prueba acotada en -dev, con presupuesto y permisos mínimos, sin acceso de escritura a producción. Computación confidencial. Problema real: los datos de tarjeta y pasajero son sensibles, pero ya están protegidos con cifrado en tránsito y en reposo, puntos privados y control de acceso; el riesgo residual que cubriría —protección frente al propio operador de la infraestructura— no está entre las amenazas prioritarias de Contoso. Madurez: disponible, pero con restricciones de tamaños y regiones y con coste superior. Coste de equivocarse: alto en esfuerzo, bajo en beneficio marginal. Veredicto: descartar por ahora y revisar si aparece un requisito contractual o regulatorio que lo exija. El criterio general que ilustra el ejercicio: se adopta lo que resuelve un problema que ya duele, se vigila lo prometedor y se descarta con fecha de revisión lo que solo resuelve un riesgo teórico.

Solución 2: no hay solución única, pero sí un patrón de plan correcto, y estos son sus elementos y los errores que evita. Punto de partida honesto: escribe qué has hecho con las manos, no qué has leído; si nunca has creado una red virtual con CLI, tu punto de partida está antes de AZ-104. Objetivo único: una certificación, con fecha de examen reservada al comenzar —reservar la fecha es lo que convierte la intención en plan— y una segunda solo esbozada. Horas realistas: entre 4 y 6 semanales sostenidas valen más que 20 en un fin de semana y cero después; para AZ-104 o AZ-204 desde una base como la de este curso, un rango plausible es de 60 a 100 horas totales, es decir, entre tres y cinco meses a ese ritmo. Hitos trimestrales: T1, recorrer la ruta de Microsoft Learn completa y montar un laboratorio propio con presupuesto y alertas; T2, práctica dirigida sobre las áreas con más peso en la lista de aptitudes medidas y primer examen de práctica al final, no al principio; T3, examen y, si sale bien, empezar la especialización; T4, práctica aplicada en un proyecto real y preparación de la siguiente. Tres carencias típicas tras este curso, que son las que hay que cubrir explícitamente: (1) fluidez con CLI y PowerShell bajo presión de tiempo —se cubre repitiendo laboratorios sin copiar comandos—; (2) detalle operativo fino de servicios que el curso trató a nivel de criterio y no de cada opción de configuración, como cuotas, límites y variantes de almacenamiento o copias —se cubre con la documentación oficial de límites—; (3) formato de examen, especialmente los casos prácticos encadenados y la gestión del tiempo —se cubre con dos o tres exámenes de práctica cronometrados—. Un plan que no nombra sus carencias no es un plan, es una intención.

Solución 3: arquitectura. Se reutiliza casi todo: oai-contoso-pro como servicio de modelo, app-contoso-reservas-pro como canal, sb-contoso-pro para desacoplar las acciones del diálogo, db-reservas como fuente de verdad y ai-insights-contoso-pro para trazas. Falta una capa de orquestación que traduzca intención en llamadas a API acotadas, una base de conocimiento con las condiciones tarifarias —recuperación aumentada, no memoria del modelo, porque las condiciones cambian y no pueden inventarse— y una barrera de acciones: el agente propone, y toda operación que cambie una reserva pasa por la misma API transaccional con sus validaciones, nunca por acceso directo a la base de datos. Seguridad e identidad: el agente es una identidad de carga de trabajo con identidad administrada y permisos mínimos, con ámbito a operaciones concretas —consultar, proponer, ejecutar un cambio dentro de límites— y sin capacidad de emitir reembolsos ni acceder a datos de tarjeta; el pasajero debe estar autenticado antes de que el agente acceda a nada suyo; hay que defenderse de la inyección de instrucciones tratando la entrada del usuario como no fiable y validando siempre en el servidor, nunca confiando en que el modelo respetará una instrucción; y todo cambio queda atribuido. Coste: modelo por tokens, muy variable con el uso y susceptible de abuso; se controla con presupuesto y alerta dedicados, cuotas por usuario y por día, límite de longitud de contexto, caché de respuestas frecuentes, elección del modelo más pequeño que cumpla y una etiqueta propia para poder ver la partida por separado; conviene además un coste unitario —euros por conversación resuelta— desde el primer día. Operación: registro de conversaciones y acciones con retención definida, medición de tasa de resolución, de escalado a persona y de errores, evaluación periódica de la calidad de las respuestas con un conjunto de casos, capacidad de desactivar la funcionalidad en segundos con un conmutador, y una ruta de escalado a agente humano siempre disponible. Regulación: RGPD por el tratamiento de datos personales en las conversaciones —base legal, minimización, retención, información al usuario— y el Reglamento de IA de la UE por tratarse de un sistema que interactúa con personas, con obligaciones de transparencia —el pasajero debe saber que habla con una máquina—, supervisión humana y documentación; el análisis de riesgo y la clasificación los valida el equipo legal, no el técnico. Recomendación: sí, con condiciones, y por fases: empezar en solo lectura —consultar estado de vuelo, equipaje y condiciones— sin capacidad de modificar nada, con escalado humano, presupuesto acotado y evaluación de calidad medida; y solo cuando haya datos de tres meses, valorar la ejecución de cambios de reserva de bajo riesgo, con confirmación explícita del pasajero y límites por importe. Lanzar directamente cambios conversacionales de reserva concentra a la vez riesgo regulatorio, financiero y reputacional, y no hay ninguna necesidad de asumir los tres el mismo día.

Aquí termina el curso. Antes de cerrarlo, merece la pena mirar el camino completo, porque desde el final se ve una distancia que desde dentro no se aprecia.

Empezaste en el módulo 1 sin saber qué era una región ni por qué importaba una zona de disponibilidad, y aprendiste a moverte por el portal, a organizar recursos con Resource Manager y etiquetas y a trabajar con la CLI. En el módulo 2 construiste lo esencial —máquinas virtuales, escalado, App Service, almacenamiento, redes, conectividad híbrida y entrega global— y dejaste de ver la nube como «servidores de otro». En el módulo 3 aprendiste lo más difícil de enseñar: elegir el servicio de datos adecuado, y lo aplicaste a SQL, Cosmos DB, MySQL, PostgreSQL y la analítica con Synapse. El módulo 4 te dio la seguridad —Entra ID, RBAC, identidades administradas, Key Vault, WAF, Defender for Cloud y directivas— y con ella la idea de que lo que no debe existir no debería poder crearse. El módulo 5 sustituyó los clics por pipelines e infraestructura como código. El módulo 6 amplió la plataforma con contenedores, Kubernetes, funciones, orquestaciones, mensajería, eventos e IA. El módulo 7 la volvió observable, automatizada y recuperable, con alertas que se miran y copias que se restauran. El módulo 8 la hizo medible y sostenible económicamente, y bajó su factura un 29 % sin degradar un solo servicio. Y este módulo 9 te ha dado lo que ninguna lección aislada podía dar: el plano completo, el marco para juzgarlo, el catálogo de lo que sale mal, el método para migrar una organización entera y el mapa de lo que viene.

Lo que puedes hacer ahora y no podías al empezar: leer una arquitectura y detectar su punto único de fallo, su acoplamiento innecesario y la pieza que sobra; elegir con criterio entre servicios que parecen equivalentes, sabiendo qué alternativa descartas y por qué; defender una decisión con los cinco pilares y admitir en voz alta qué estás sacrificando a cambio; estimar lo que costará algo antes de construirlo y explicar la factura después; diseñar para el fallo en lugar de para el camino feliz; desplegar sin miedo porque hay reversión, y operar sin héroes porque hay observabilidad; planificar una migración con inventario, oleadas, ventana de corte y vuelta atrás; y reconocer, en una plataforma que no has construido tú, las señales de que hay deuda esperando.

Queda una cosa que este curso no puede darte y que solo llega con el oficio: el juicio que se forma tomando decisiones que tienen consecuencias, viendo cuáles envejecen bien y cuáles no, y escribiendo por qué. Por eso la última recomendación es también la más sencilla: construye algo. Pequeño, propio, con su presupuesto y su alerta, con su plantilla y su pipeline, y bórralo y recréalo hasta que te salga sin pensar. La plataforma de Contoso Airlines no existe, pero el criterio que has usado para levantarla sí, y ese viaja contigo a cualquier organización, a cualquier proveedor de nube y a cualquier problema que te pongan delante.

Gracias por llegar hasta aquí. Ha sido un recorrido largo y exigente, de la primera suscripción vacía a una plataforma completa, gobernada, observada, optimizada y bien entendida. Ahora te toca a ti.