Microsoft AZ-900: Conceptos de la nube — Guía de estudio

By Laurynas Brazys · 22 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

La computación en la nube (cloud computing) entrega recursos de TI medidos a través de internet con aprovisionamiento rápido, alcance global y resiliencia integrada. Migrar de una infraestructura local (on-premises) a Azure cambia tanto las opciones tecnológicas como los modelos operativos: la planificación de capacidad da paso al escalado elástico, las compras de capital se convierten en gasto operativo y el mantenimiento del hardware pasa a ser una responsabilidad de la plataforma. Comprender estos conceptos es esencial para seleccionar los servicios adecuados, diseñar arquitecturas para la disponibilidad y controlar los costos.

Características principales de la nube: escalabilidad, elasticidad, agilidad y resiliencia

La escalabilidad es la capacidad de una carga de trabajo para manejar un aumento de la demanda mediante la adición de recursos. En Azure, esto toma dos formas: el escalado vertical (scale up), eligiendo tamaños de VM más grandes o planes de App Service superiores, y el escalado horizontal (scale out), añadiendo más instancias a través de Virtual Machine Scale Sets (VMSS), grupos de nodos de Azure Kubernetes Service (AKS) o el autoescalado de App Service. El escalado en la dirección opuesta reduce la capacidad y el costo cuando la demanda disminuye. Diseñar niveles sin estado (stateless) y externalizar el estado (por ejemplo, a Azure Cache for Redis o Azure SQL Database) hace que el escalado horizontal sea predecible y rápido. La elasticidad es el escalado automatizado y basado en políticas que alinea continuamente la capacidad con la carga. Las reglas de autoescalado de Azure Monitor, el autoescalador de clústeres de AKS y las opciones sin servidor (serverless) como Azure Functions o los planes de Consumo/Elastic Premium expanden y contraen los recursos casi en tiempo real. Las arquitecturas elásticas minimizan la capacidad inactiva y son muy adecuadas para cargas de trabajo con picos o estacionales, ajustando el gasto precisamente al uso. La agilidad es la velocidad con la que los equipos entregan cambios. El despliegue de recursos de Azure a través de plantillas Bicep o ARM, las canalizaciones (pipelines) de GitHub Actions o Azure DevOps, y las abstracciones de recursos como App Service o AKS permiten lanzamientos frecuentes y de bajo riesgo. El aprovisionamiento de autoservicio a través de RBAC y las barreras de protección de políticas (policy guardrails) reduce los tiempos de espera mientras se mantiene la gobernanza. La agilidad es producto tanto de la plataforma como de las prácticas organizativas; cuanto más abstrae la plataforma el trabajo pesado no diferenciado (undifferentiated heavy lifting), más rápido pueden moverse los equipos. La tolerancia a fallos y la recuperación ante desastres abordan diferentes ámbitos de fallo. La tolerancia a fallos mitiga los fallos de componentes y de centros de datos dentro de una región utilizando Availability Sets (distribuyendo las VM entre dominios de error/actualización), Availability Zones (centros de datos físicamente separados dentro de una región), balanceadores de carga y rutas de datos redundantes. La recuperación ante desastres se prepara para interrupciones a nivel de región con replicación entre regiones (almacenamiento GRS/RA-GRS, geo-replicación activa de Azure SQL, escrituras multirregión de Cosmos DB) y herramientas de recuperación como Azure Site Recovery. Defina objetivos claros de RTO/RPO y pruebe la conmutación por error (failover) para garantizar que el diseño cumpla con los objetivos de continuidad del negocio.

Modelos de servicio y responsabilidad compartida

Los modelos de servicio en la nube determinan qué gestionas tú frente a qué gestiona Azure. La Infraestructura como Servicio (IaaS) expone componentes básicos de cómputo, almacenamiento y redes en bruto. Tú controlas el SO invitado, el entorno de ejecución y las aplicaciones, lo cual es ideal cuando necesitas imágenes personalizadas, middleware especializado o control total. La Plataforma como Servicio (PaaS) abstrae el SO y gran parte del middleware, proporcionando entornos de ejecución gestionados, bases de datos y servicios de integración para que los equipos puedan centrarse en el código y los datos. El Software como Servicio (SaaS) entrega aplicaciones completas que se consumen a través de un navegador o API con una configuración mínima y sin obligaciones de alojamiento de aplicaciones. El modelo de responsabilidad compartida clarifica los límites operativos. En IaaS, Azure gestiona el centro de datos físico, los hosts y el hipervisor; tú te encargas de la aplicación de parches al SO, el fortalecimiento (hardening), las actualizaciones de aplicaciones, la identidad y el acceso, y la gobernanza de datos. En PaaS, Azure también gestiona el SO y el middleware de la plataforma; tú gestionas el código de la aplicación, la configuración y los datos. En SaaS, Azure (o el proveedor de SaaS) opera toda la pila (stack); tú gestionas los usuarios, el acceso, la clasificación de datos y la configuración de uso. En todos los modelos, los clientes conservan la responsabilidad sobre la identidad, los permisos, la seguridad de los puntos de conexión (endpoints) y las políticas de protección de datos. Seleccionar el modelo correcto afecta a los objetivos de disponibilidad y al costo. Desplegar máquinas virtuales de Azure es una tarea de IaaS; las API web en Azure App Service o los contenedores en AKS reflejan PaaS; Microsoft 365 y Dynamics 365 son SaaS. Favorece PaaS y SaaS siempre que sea posible para acelerar la entrega y reducir la carga operativa, reservando IaaS para cargas de trabajo que requieran control a nivel de SO o que tengan dependencias heredadas (legacy).

• IaaS
  • Servicios típicos de Azure: Azure Virtual Machines, VM Scale Sets, Azure Disks, Virtual Network
  • Lo que tú gestionas: SO invitado, parches, entorno de ejecución, aplicaciones, datos, copias de seguridad, AV/EDR
  • Cuándo elegirlo: Control total del SO, middleware personalizado, lift-and-shift
• PaaS
  • Servicios típicos de Azure: Azure App Service, Azure SQL Database/Managed Instance, AKS, Azure Functions, Azure Integration Services
  • Lo que tú gestionas: Código/configuración, esquema, datos, identidad y acceso
  • Cuándo elegirlo: Entrega más rápida, escalado/alta disponibilidad integrados, operaciones reducidas
• SaaS
  • Servicios típicos de Azure: Microsoft 365, Dynamics 365, Power BI, Azure DevOps Services
  • Lo que tú gestionas: Usuarios, roles, uso/configuración de datos
  • Cuándo elegirlo: Aplicaciones completas con una gestión mínima

Modelos de despliegue y alcance de la escala

La nube pública despliega cargas de trabajo en centros de datos propiedad de Microsoft que se comparten entre múltiples inquilinos con aislamiento lógico. Ofrece el catálogo más amplio, alcance global, aprovisionamiento rápido y un modelo puro de pago por uso (pay-as-you-go). La nube privada dedica infraestructura a una única organización, a menudo por razones regulatorias o de soberanía de datos, y puede ejecutarse en pilas validadas por Azure como Azure Stack Hub o Azure Stack HCI. La nube híbrida conecta los entornos locales (on-premises) y Azure con identidad, políticas y redes consistentes, permitiendo migraciones por fases y localidad de datos, al tiempo que aprovecha la elasticidad de la nube donde tiene sentido. El escalado global frente al local se refiere al alcance de las mejoras de disponibilidad y rendimiento. El escalado local mantiene el tráfico dentro de una región, utilizando Availability Zones, VM Scale Sets, Application Gateway y Azure Load Balancer para añadir instancias y aislar fallos del centro de datos. El escalado global distribuye el tráfico entre regiones utilizando Azure Front Door (balanceo de carga global moderno, anycast, de capa 7 con WAF), Azure Traffic Manager (balanceo de carga basado en DNS) y servicios de datos con replicación geográfica como la geo-replicación de Azure SQL o la distribución multirregional de Cosmos DB. Los diseños multirregionales activo/activo mejoran la latencia y la resiliencia, pero requieren una planificación cuidadosa de la consistencia de los datos y los costos. La elección de un modelo de despliegue a menudo comienza con las restricciones de cumplimiento y conectividad y evoluciona con el ciclo de vida de la aplicación. Las nuevas aplicaciones web de tipo greenfield frecuentemente se implementan en PaaS de nube pública por su velocidad y escalabilidad. Los sistemas de línea de negocio complejos con dependencias pueden comenzar como híbridos —reteniendo ciertos servicios en el entorno local mientras que los front-ends y las capas sin estado (stateless) se mueven a Azure— antes de completar la transición a medida que se modernizan las dependencias.

• Pública
  • Propiedad/Ubicación: Regiones propiedad de Microsoft
  • Acceso típico: Internet/VPN/ExpressRoute
  • Casos de uso: Escalado elástico, alcance global, innovación rápida
  • Ejemplos de Azure: La mayoría de los servicios de Azure, Azure Front Door, Azure App Service
• Privada
  • Propiedad/Ubicación: Infraestructura dedicada al cliente (local u hospedada)
  • Acceso típico: Redes privadas
  • Casos de uso: Soberanía, cargas de trabajo aisladas, cumplimiento estricto
  • Ejemplos de Azure: Azure Stack Hub, Azure Stack HCI, AKS on HCI
• Híbrida
  • Propiedad/Ubicación: Mezcla de entorno local y Azure
  • Acceso típico: VPN de sitio a sitio o ExpressRoute
  • Casos de uso: Migración por fases, localidad de datos, integración de sistemas heredados
  • Ejemplos de Azure: Azure VPN Gateway, ExpressRoute, Azure Arc

Modelos de costos: CapEx vs. OpEx, precios por consumo, pago por uso y capacidad reservada

La adquisición de infraestructura local (on-premises) es típicamente un gasto de capital (CapEx): grandes compras iniciales de servidores, almacenamiento y redes que se deprecian a lo largo de los años. Azure invierte este modelo hacia un gasto operativo (OpEx): los servicios se miden y facturan según el consumo real —segundos de CPU, GB-mes, transacciones— trasladando el gasto al momento en que se obtiene el valor. Este modelo de precios basado en el consumo reduce el sobreaprovisionamiento y vincula el costo a los patrones de uso. El pago por uso (Pay-as-you-go) maximiza la flexibilidad: inicie y detenga recursos a voluntad sin compromiso de permanencia. Para cargas de trabajo estables, Azure ofrece descuentos basados en reservas como Reserved Virtual Machine Instances, capacidad reservada de Azure SQL Database, reservas de RU/s de Cosmos DB y capacidad reservada de Storage. Los compromisos de uno o tres años pueden generar ahorros significativos, al tiempo que opcionalmente permiten flexibilidad en el tamaño de la instancia y un alcance compartido entre suscripciones. Otras opciones complementarias incluyen los Azure Savings Plans for Compute, que aplican tarifas con descuento a los servicios de cómputo elegibles, y las Spot VMs para cargas de trabajo interrumpibles tipo batch con grandes descuentos. Una gobernanza de costos eficaz combina el modelo comercial adecuado con controles de ingeniería. El escalado automático (Autoscale) reduce la capacidad inactiva; los niveles sin servidor (serverless) eliminan la infraestructura cuando está inactiva; Azure Hybrid Benefit aplica las licencias existentes de Windows Server y SQL Server; los precios de Dev/Test reducen el gasto en entornos de no producción. Azure Cost Management + Billing proporciona presupuestos, detección de anomalías y asignación de costos para una optimización continua.

• Pago por uso
  • Compromiso: Ninguno
  • Descuento típico vs. PAYG: 0%
  • Flexibilidad: Máxima flexibilidad; iniciar/detener en cualquier momento
  • Ideal para: Cargas de trabajo impredecibles o de corta duración
• Reserved VM Instances / Capacidad reservada
  • Compromiso: 1 o 3 años
  • Descuento típico vs. PAYG: Hasta ~72% (con Azure Hybrid Benefit)
  • Flexibilidad: El alcance puede ser compartido; se permite el intercambio; cargos por cancelación anticipada
  • Ideal para: Cómputo estable 24x7, bases de datos, Cosmos DB
• Savings Plan for Compute
  • Compromiso: Compromiso de gasto de 1 o 3 años
  • Descuento típico vs. PAYG: Hasta ~65%
  • Flexibilidad: Se aplica a VMs, AKS, Functions Premium, App Service
  • Ideal para: Cómputo mixto con tipos de instancia variables
• Spot VMs
  • Compromiso: Ninguno (dependiente de la capacidad)
  • Descuento típico vs. PAYG: Hasta ~90%
  • Flexibilidad: Pueden ser desalojadas; sin SLA
  • Ideal para: Trabajos por lotes (batch), sin estado (stateless), CI, renderización

Problema práctico: PeakGear Retail: escalado estacional con control de costos y resiliencia

Escenario: PeakGear Retail opera un sitio de comercio electrónico con picos de tráfico predecibles a fin de mes y en días festivos. La empresa quiere migrar de VMs on-premises a Azure, reducir el gasto de capital (CapEx), mantener un objetivo de disponibilidad del 99.99% para el nivel web e implementar un plan de recuperación ante desastres con un RTO de cuatro horas y un RPO de 15 minutos. La identidad debe integrarse con los usuarios existentes a través de Microsoft Entra ID.

Desafío: Diseñar una arquitectura y un modelo de costos en Azure que ofrezca escalado elástico para los aumentos de tráfico, tolerancia a fallos a nivel de zona, recuperación ante desastres entre regiones y simplicidad operativa, minimizando el costo durante los períodos de baja demanda.

Enfoque recomendado:

1. Desplegar la API web y la tienda (storefront) en Azure App Service (PaaS) utilizando planes Premium v3 para obtener autoescalado integrado, aplicación de parches de plataforma gestionada y opciones de redundancia de zona.
2. Colocar dos o más instancias de App Service detrás de Azure Front Door Standard/Premium para una entrada global anycast, terminación SSL, WAF y enrutamiento basado en rutas; habilitar sondeos de estado (health probes) y afinidad de sesión según sea necesario.
3. Usar Azure SQL Database Business Critical con redundancia de zona en la región primaria; configurar la georreplicación activa a una región secundaria emparejada con el objetivo de un RPO de 15 minutos.
4. Almacenar contenido estático en Azure Storage con RA-GRS; servirlo a través de Azure CDN from Microsoft para descargar el ancho de banda y mejorar la latencia.
5. Implementar reglas de autoescalado basadas en CPU, solicitudes y profundidad de la cola para escalar horizontalmente (scale out) durante los picos y reducir (scale in) durante los períodos de calma; para trabajos en segundo plano, usar planes Consumption o Elastic Premium de Azure Functions.
6. Alcanzar una disponibilidad del 99.99% en el nivel web habilitando la redundancia de zona (multi-zona) para el plan de App Service o distribuyendo las instancias entre Zonas de Disponibilidad donde esté soportado.
7. Adoptar el modelo de pago por uso (pay-as-you-go) inicialmente para mayor flexibilidad; para la capacidad base estable identificada después de 30 días, comprar una Reserved Instance de 1 año para los planes de App Service (a través de un Savings Plan for Compute que cubra App Service) y capacidad reservada para SQL Database para reducir el costo operativo continuo.
8. Integrar Microsoft Entra ID para el acceso de usuarios y administradores; aplicar el principio de privilegio mínimo con roles integrados y acceso condicional; proteger los secretos en Azure Key Vault, referenciados por App Service y las canalizaciones (pipelines) de despliegue.
9. Definir y probar los manuales de procedimientos (runbooks) de DR: realizar la conmutación por error (failover) de SQL al secundario, actualizar las prioridades de origen de Front Door para activar la región secundaria y validar la salud de la aplicación dentro de un RTO de cuatro horas.
10. Implementar Azure Monitor y Log Analytics para centralizar métricas, trazas y registros (logs); configurar alertas y paneles (dashboards); establecer presupuestos y alertas de anomalías en Azure Cost Management para optimizar el gasto continuamente.

Justificación de Azure: Los servicios PaaS (App Service y Azure SQL Database) maximizan la agilidad y delegan el mantenimiento del SO y la plataforma bajo el modelo de responsabilidad compartida, a la vez que habilitan el autoescalado para la elasticidad. El despliegue con redundancia de zona y la replicación multirregional proporcionan tolerancia a fallos dentro de una región y recuperación ante desastres entre regiones que cumplen con el RPO/RTO establecidos. Front Door proporciona una entrada global, enrutamiento basado en el estado de salud y protección WAF. Comenzar con el modelo de pago por uso preserva la flexibilidad durante la migración; comprometerse con capacidad reservada o un Savings Plan para la línea base medida reduce el costo del uso constante, mientras que el autoescalado recorta el gasto durante los períodos de baja demanda. Microsoft Entra ID centraliza la identidad y el control de acceso, y Azure Monitor con Cost Management mantiene la visibilidad operativa y financiera.

Todos los dominios · Arquitectura e infraestructura global de Azure →

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

Explorar Microsoft →