En el examen AZ-305 de Solution Architect, el dominio de Identidad y Gestión de Acceso representa aproximadamente el 20–25% del total de preguntas. Más allá de memorizar roles de RBAC, se requiere la capacidad de diseñar quién puede acceder a qué, con qué credencial y en qué ámbito. Esta guía cubre los conceptos clave de Entra ID, la herencia de RBAC, Conditional Access, Managed Identity y Privileged Identity Management — los temas más frecuentes en el examen — acompañados de escenarios prácticos. Tanto si estás comenzando con AZ-305 como si eres un ingeniero de nube experimentado, encontrarás criterios de decisión aplicables de inmediato.
---
Conceptos clave de Entra ID
Microsoft Entra ID (antes Azure Active Directory) es la columna vertebral de la gestión de acceso en Azure. Al igual que una credencial determina a qué áreas de un edificio puedes entrar, Entra ID decide qué recursos en la nube puede acceder cada identidad.
Permiso delegado vs Permiso de aplicación
El Permiso delegado (Delegated Permission) implica que una aplicación actúa en nombre del usuario que inició sesión. Solo accede a recursos dentro del ámbito al que el usuario ha consentido explícitamente, usando el Authorization Code Flow. Por ejemplo, cuando una aplicación web necesita leer el calendario del usuario conectado, utiliza Calendars.Read (Delegated).
El Permiso de aplicación (Application Permission) significa que la app opera bajo su propia identidad sin ningún usuario presente. Usa el Client Credentials Flow, y el Admin Consent es obligatorio. Cuando una API backend define App Roles y esos roles se asignan como permisos de aplicación a una app cliente, aparecen en el claim del token de acceso.
Guía de palabras clave: si ves "en nombre del usuario" o "consentimiento del usuario," elige Permiso delegado. Si ves "autenticación entre servicios sin intervención del usuario," elige Permiso de aplicación.
Administrative Units y administración delegada
Para que los administradores de TI de cada departamento gestionen solo los usuarios de su departamento, asigna el rol User Administrator con ámbito en la Administrative Unit (AU) correspondiente. El rol Helpdesk Administrator no puede crear nuevos usuarios, por lo que si se requiere crear cuentas, debes seleccionar User Administrator.
Identidad híbrida: PHS vs PTA vs AD FS
Password Hash Synchronization (PHS) sincroniza los hashes de contraseña con Entra ID, de modo que la autenticación en la nube continúa aunque el AD local caiga. Pass-through Authentication (PTA) redirige las solicitudes de autenticación a un agente local, por lo que si se pierde la conexión local, la autenticación falla.
Consejo para el examen: si el requisito es "mantener la autenticación en la nube incluso durante una interrupción local," elige PHS. Si "las contraseñas no deben almacenarse en la nube," elige PTA o AD FS. Microsoft Entra Connect puede sincronizar varios bosques de AD local en un solo tenant de Entra; los dominios hijo dentro de un único bosque se gestionan con un solo agente.
!Identidad híbrida: PHS, PTA y AD FS
Diseño de RBAC y delegación de permisos
RBAC (Role-Based Access Control) es como dar diferentes llaves según el puesto de trabajo. Las asignaciones de roles de Azure RBAC se heredan automáticamente de ámbitos superiores a ámbitos inferiores.
Asignar un rol a nivel de Management Group se aplica automáticamente a todas las suscripciones y recursos secundarios, sin configuración adicional. Los grupos anidados también son compatibles, de modo que un rol en un grupo padre se propaga a los miembros de grupos hijos.
Limitación clave: las asignaciones de roles de RBAC no cruzan los límites del tenant. Para otorgar acceso de Reader a cinco suscripciones distribuidas en dos tenants de Entra independientes, asigna a nivel de Management Group una vez por tenant — un total de dos asignaciones.
Limitación de Contributor: Contributor puede crear, modificar y eliminar recursos, pero no incluye . Si necesitas asignar roles a otros usuarios, se requiere Owner o User Access Administrator.
ABAC permite refinar el acceso según atributos del recurso (etiquetas, nombres de contenedor) sin modificar los roles existentes. Actualmente solo está soportado en operaciones del plano de datos de Azure Blob Storage — Files, Queue y Table Storage no están soportados.
---
Conditional Access y estrategia MFA
Conditional Access es el motor de políticas Zero Trust que evalúa señales compuestas — usuario, dispositivo, ubicación, aplicación y nivel de riesgo — y responde con Permitir, Bloquear o una solicitud de autenticación adicional.
Forzar el registro de MFA y forzar el inicio de sesión con MFA son cosas distintas. Forzar el registro de MFA usa la política de registro de MFA de Conditional Access para que los usuarios inscriban un método de MFA. Forzar el inicio de sesión con MFA configura la opción "Requerir MFA" en el control de concesión (Grant), de modo que el acceso solo se permite tras completar la autenticación MFA.
Para bloquear BYOD y permitir acceso solo desde dispositivos administrados, configura la condición "Dispositivo conforme (Compliant Device)." Azure Firewall y NSG no entienden el estado de administración del dispositivo, por lo que siempre usa Conditional Access para el control de acceso basado en dispositivos.
Requerir MFA para administradores que acceden al Azure Portal se resuelve con una sola política que combina el grupo de usuarios, la aplicación en la nube (Microsoft Azure Management) y el control de concesión (Requerir MFA).
Seguridad de acceso a VM: usa Azure Bastion cuando necesites acceso RDP/SSH sin exponer una IP pública. JIT VM Access abre temporalmente un puerto público, así que si el requisito es "eliminar la exposición de IP pública," elige Bastion + Conditional Access.
---
Managed Identity y autenticación de servicios
Usa Managed Identity cuando necesites autenticación entre servicios de Azure sin almacenar credenciales en el código o archivos de configuración. La plataforma Azure emite y renueva tokens automáticamente, eliminando la gestión de expiración y rotación.
System-assigned Managed Identity tiene un ciclo de vida vinculado al recurso de Azure específico. Cuando el recurso se elimina, la identidad se elimina automáticamente también. User-assigned Managed Identity puede compartirse entre varios recursos.
Consejo para el examen: si cada recurso necesita una credencial independiente, elige System-assigned. Si varios recursos comparten la misma identidad, elige User-assigned.
Patrón de integración con Key Vault: asigna el rol "Key Vault Secrets User" a la Managed Identity para acceder a secretos sin ningún cambio en el código. Si la autenticación tiene éxito pero las lecturas fallan, falta el paso de autorización. La autenticación exitosa de Managed Identity solo confirma la identidad; leer un secreto requiere permisos de Get/List por separado.
Para obtener un token de Managed Identity desde dentro de una VM usando solo llamadas REST (sin SDK), usa el Azure Instance Metadata Service (IMDS).
---
Tabla comparativa de servicios
| Servicio | Uso principal | Licencia | Característica clave | |----------|---------------|----------|----------------------| | Entra ID PIM | Gestión de roles privilegiados JIT | P2 | Asignación Eligible, flujo de aprobación, registro de auditoría | | Access Reviews | Revisión periódica de derechos de acceso | P2 | Programación recurrente, autorrevisión, eliminación automática sin respuesta | | Entitlement Management | Acceso temporal para usuarios externos | P2 | Paquetes de acceso, expiración automática, solicitud de autoservicio | | Conditional Access | Motor de políticas de acceso condicional | P1 | Evaluación de señales compuestas: usuario/dispositivo/ubicación/app | | Application Proxy | Publicar apps locales sin VPN | P1 | Proxy inverso, soporte KCD, sin cambios de código | | Entra Domain Services | Dominio LDAP/Kerberos totalmente administrado | SKU separada | Sin conectividad local, compatible con apps heredadas |
---
Criterios de selección que suelen confundir en el examen
Criterios de decisión basados en patrones de escenarios reales del examen.
PIM vs Access Reviews — PIM controla cuándo se activa un rol; Access Reviews determina periódicamente quién debe seguir teniendo un rol. Cuando ambos requisitos aparecen juntos, elige PIM + Access Reviews.
Application Proxy vs Azure Bastion — Application Proxy publica aplicaciones web basadas en HTTP/HTTPS en internet sin VPN. Azure Bastion es exclusivamente para acceso RDP/SSH a VMs. Para acceso SSO a una app IWA local sin VPN, elige Application Proxy.
Entra B2B vs B2C — Si los empleados de socios ya tienen cuentas de Entra ID, usa la invitación de invitado B2B. Si el público objetivo son consumidores o usuarios con cuentas sociales, elige B2C.
Entra Domain Services vs Entra Connect — Si una app heredada usa autenticación LDAP y no debe haber conectividad local, elige Entra Domain Services. Si el objetivo es sincronizar usuarios de AD local en Entra ID, usa Entra Connect.
Selección de flujo OAuth 2.0 — Cuando una aplicación web llama a una API backend en nombre de un usuario conectado, usa el On-Behalf-Of (OBO) Flow. Para llamadas entre servicios sin usuario, usa Client Credentials Flow. Para un usuario que inicia sesión directamente en una app, usa Authorization Code Flow.
---
Consejos prácticos para aplicación en el mundo real
Convierte las asignaciones de roles permanentes a asignaciones Eligible (PIM) siempre que sea posible. Requerir activación bajo demanda reduce el riesgo de abuso de privilegios. Minimiza el número de asignaciones usando grupos, teniendo en cuenta el límite de 4.000 asignaciones de roles por suscripción.
Aprovecha al máximo la jerarquía de Management Groups. A medida que crece el número de suscripciones, asignar roles individualmente a cada una se vuelve ineficiente. Asignar un rol una sola vez a niv