Guía completa
AZ-305 Cloud Solutions Architect
Toca cualquier servicio para ver más detalles y documentación oficial.
Distribución del examen
40–60
Preguntas
~60
Min lectura
700
Puntaje mínimo
Identidad, gobernanza y monitoreo
25–30% del examenDiseño de identidad empresarial
En AZ-305 el foco está en DISEÑAR soluciones de identidad para requisitos de negocio complejos, no solo configurarlas.
| Escenario | Solución recomendada |
|---|---|
| Empleados de la organización | Entra ID con MFA y Conditional Access |
| Partners externos (B2B) | Entra ID B2B — invitar como guest users |
| Clientes finales (B2C) | Entra ID B2C — identidades de consumidores |
| Apps que necesitan acceder a Azure | Managed Identity — sin secretos en código |
| Múltiples tenants de Entra ID | Azure Lighthouse o B2B cross-tenant access |
| On-premises AD + Azure AD (híbrido) | Entra ID Connect para sincronización |
Gobernanza a escala — Landing Zones
Para grandes organizaciones, la gobernanza se diseña con una jerarquía de Management Groups, políticas heredadas y Landing Zones.
Management Groups
Organiza suscripciones en árbol jerárquico. Las políticas se heredan hacia abajo.
Azure Policy
Aplica reglas de cumplimiento automáticamente en toda la jerarquía.
Blueprints
Empaqueta políticas, roles y plantillas ARM para despliegues repetibles.
Landing Zone
Entorno base con identidad, red, seguridad y gobernanza preconfigurados.
Diseño de monitoreo
Haz clic en cualquier servicio para ver más detalles
| Herramienta | Propósito en arquitectura |
|---|---|
| Log Analytics Workspace | Repositorio central — consolida logs de toda la plataforma |
| Application Insights | APM para apps — trazas, excepciones, performance, usuarios |
| Microsoft Sentinel | SIEM/SOAR — threat detection e investigación de seguridad |
| Azure Monitor Workbooks | Dashboards personalizables para NOC o reporting ejecutivo |
Managed Identity es siempre la primera opción para autenticar apps contra recursos Azure. Evita gestionar secretos, rotaciones y accesos. El examen lo prefiere sobre Service Principals con client secrets.
Soluciones de almacenamiento de datos
20–25% del examenSelección del almacenamiento correcto
| Requisito | Servicio recomendado |
|---|---|
| Datos relacionales transaccionales | Azure SQL Database o SQL Managed Instance |
| Alta escala global con baja latencia | Azure Cosmos DB |
| Datos no estructurados (archivos, blobs) | Azure Blob Storage |
| Data warehouse y análisis a escala | Azure Synapse Analytics |
| Cache de sesión o datos hot | Azure Cache for Redis |
| Archivos compartidos entre VMs | Azure Files |
| Time series / IoT data | Azure Data Explorer o ADX |
Bases de datos principales
Haz clic en cualquier servicio para ver más detalles
Seguridad en datos
Haz clic en cualquier servicio para ver más detalles
| Tipo de dato | Dónde guardar en Azure |
|---|---|
| Connection strings, API keys | Azure Key Vault (secretos) |
| Claves de cifrado TDE/CMK | Azure Key Vault (claves) |
| Certificados TLS/SSL | Azure Key Vault (certificados) |
| Datos en reposo | Azure Storage Encryption (AES-256 por defecto) |
| Datos en tránsito | TLS/HTTPS — habilitado por defecto en servicios Azure |
Customer-Managed Keys (CMK) dan control total sobre el cifrado pero añaden complejidad operativa. Si pierdes la clave en Key Vault, pierdes acceso a los datos. Requiere cuidadosa gestión del lifecycle de claves.
Continuidad de negocio
15–20% del examenRPO, RTO y SLA — el triángulo del BCDR
RPO
Recovery Point Objective
¿Cuántos datos puedes perder? Tiempo máximo de pérdida de datos.
RTO
Recovery Time Objective
¿Cuánto tiempo puedes estar caído? Tiempo máximo de recuperación.
SLA
Service Level Agreement
Disponibilidad comprometida. 99.99% = máx. 52 min/año de downtime.
| Nivel de disponibilidad | SLA | Downtime/año | Cómo lograrlo |
|---|---|---|---|
| 99.9% | 3 nines | ~8.7 horas | Single instance en Availability Set |
| 99.95% | 3.5 nines | ~4.4 horas | Multi-instance en Availability Set |
| 99.99% | 4 nines | ~52 minutos | Availability Zones (multi-zona) |
| 99.999% | 5 nines | ~5 minutos | Multi-región activo-activo |
Servicios de BCDR
Haz clic en cualquier servicio para ver más detalles
| Patrón | RTO | RPO | Costo | Descripción |
|---|---|---|---|---|
| Backup & Restore | Horas | Horas | $ | Restaurar desde backup. Más lento y barato. |
| Pilot Light | Minutos | Minutos | $$ | Infraestructura mínima en DR siempre activa. |
| Warm Standby | Minutos | Segundos | $$$ | Copia reducida del ambiente siempre activa. |
| Active/Active | Segundos | Segundos | $$$$ | Ambas regiones activas, tráfico distribuido. |
Para el examen: si el requisito es RPO en minutos y RTO en segundos → activo/activo multi-región. Si RPO/RTO es en horas → Backup & Restore puede ser suficiente y más económico.
Soluciones de infraestructura
30–35% del examenDiseño de red y balanceo de carga
Haz clic en cualquier servicio para ver más detalles
| Servicio | Capa | Scope | Cuándo usarlo |
|---|---|---|---|
| Load Balancer | L4 | Regional | TCP/UDP entre VMs en misma región |
| Application Gateway | L7 | Regional | HTTP/S con WAF y routing por URL |
| Traffic Manager | DNS | Global | Routing global entre regiones o endpoints |
| Azure Front Door | L7 | Global | CDN + WAF + aceleración global en L7 |
Diagrama interactivo — observa cómo el tráfico fluye desde on-premises a través del hub hacia cada spoke. Pasa el cursor sobre cada nodo.
Patrón Hub-Spoke
El patrón más común para redes empresariales en Azure. Una VNet central (hub) conecta múltiples VNets de workloads (spokes) via peering.
Hub VNet
Contiene servicios compartidos: Firewall, VPN Gateway, Bastion, DNS
Spoke VNets
Cada workload en su propia VNet — dev, prod, HR, etc. Peered con hub
Peering
Las spokes se comunican entre sí SOLO a través del hub (via firewall)
Compute: elegir el servicio correcto
| Requisito | Mejor opción |
|---|---|
| Control total del SO, licencias especiales | Azure Virtual Machines (IaaS) |
| App web sin gestionar servidores | Azure App Service (PaaS) |
| Microservicios en contenedores a escala | Azure Kubernetes Service |
| Funciones event-driven, pago por ejecución | Azure Functions (Serverless) |
| Contenedores rápidos sin orquestación | Azure Container Instances |
| Alta disponibilidad cross-región para VMs | Scale Sets + Availability Zones |
D4 tiene el mayor peso (30-35%). El examen da un escenario de negocio y pide la MEJOR arquitectura. Memoriza cuándo usar cada servicio de cómputo, red y los trade-offs entre ellos.
Arquitectura de aplicaciones
15–20% del examenIntegración y mensajería
Haz clic en cualquier servicio para ver más detalles
Mensajería: elegir el servicio correcto
| Servicio | Modelo | Caso de uso |
|---|---|---|
| Azure Service Bus | Push — colas y topics | Mensajería transaccional: órdenes, pagos, garantías de entrega |
| Azure Event Hubs | Pull — partitions | Streaming masivo: telemetría IoT, logs, clickstream |
| Azure Event Grid | Push — pub/sub reactivo | Eventos de recursos Azure: blob creado, VM stopped, etc. |
| Queue Storage | Pull — simple | Cola simple y económica para decoupling básico |
Integración de IA Generativa en arquitecturas
Haz clic en cualquier servicio para ver más detalles
Patrón RAG — arquitectura de referencia
1. Azure AI Search — indexa y recupera documentos relevantes
2. Azure OpenAI Embeddings — genera vectores para búsqueda semántica
3. Azure OpenAI GPT-4 — genera respuesta basada en contexto recuperado
4. Azure API Management — expone la solución como API segura
5. Azure Monitor — monitorea uso, latencia y calidad de respuestas
Service Bus vs Event Hubs es una pregunta frecuente. Service Bus garantiza entrega exactamente una vez (exactly-once) — ideal para transacciones. Event Hubs es para telemetría de alta frecuencia donde alguna pérdida puede ser aceptable.
Tips para el día del examen
AZ-305 evalúa DECISIONES de diseño, no solo qué es cada servicio. La pregunta siempre es "cuál es la MEJOR solución para este requisito".
Costo siempre importa. Si hay dos soluciones técnicamente válidas, el examen suele preferir la más económica a menos que haya un requisito específico.
RPO vs RTO: RPO = cuántos datos puedes perder. RTO = cuánto tiempo puedes estar caído. Diseña la solución de BCDR que cumple ambos.
Traffic Manager = DNS routing global. Azure Front Door = CDN + WAF + L7. Load Balancer = L4 regional. Application Gateway = L7 regional con WAF.
Azure SQL = relacional PaaS. Cosmos DB = NoSQL globalmente distribuido. Redis = cache en memoria. Cada uno tiene su caso de uso específico.
Event Hubs = streaming de alta frecuencia (IoT, logs). Service Bus = mensajería transaccional (órdenes, pagos). Queue Storage = cola simple y económica.
Para integración entre sistemas: Logic Apps (low-code, 400+ conectores) vs Azure Functions (código custom) vs APIM (gestión de APIs).
Landing Zone = entorno base con identidad, networking, políticas y seguridad configurados. Es el punto de partida para migrar a Azure de forma estructurada.
El examen pide diseñar para el requisito MÁS RESTRICTIVO: si necesitas 99.99% de SLA, solo Availability Zones o geo-redundancy lo garantizan.
Managed Identity > Service Principal > Access Keys. Siempre prefiere Managed Identity para que las apps accedan a recursos Azure — no hay secretos que gestionar.
¿Quieres más profundidad?
Esta guía es un resumen rápido. Visita la sección Deep Dive para exploración exhaustiva con casos reales, análisis de costos y decisiones arquitectónicas.
¿Listo para poner a prueba lo aprendido?
Practica AZ-305 con preguntas originales. Disponible con plan Pro o compra individual — crea tu cuenta para empezar.