SAA-C03
Deep Dive
IAM es el pilar de seguridad más importante en SAA-C03. El 30% del examen (D1) gira en torno a controlar el acceso correctamente. Necesitas entender cómo se evalúan permisos, cuándo usar roles vs usuarios, y cómo las SCPs limitan toda una cuenta.
Contenido
AWS IAM (Identity and Access Management) controla quién puede autenticarse en AWS y qué puede hacer una vez autenticado. Es global — no pertenece a ninguna región.
Principio fundamental del examen: mínimo privilegio — dar solo los permisos estrictamente necesarios para que una identidad realice su función.
Evaluación de permisos (orden de prioridad)
Deny explícito
Si existe un Deny en CUALQUIER política, acceso denegado. Siempre gana.
SCPs (Organizations)
Si la cuenta está en una OU con SCP, el SCP limita lo máximo que IAM puede permitir.
Resource-based policies
Políticas en el propio recurso (S3 bucket policy, SQS queue policy).
Identity-based policies
Políticas adjuntas a usuario, grupo o rol.
Permission Boundaries
Límite máximo de lo que una identidad puede recibir como permiso.
IAM Users
Identidad permanente con credenciales de larga duración (contraseña + access keys).
Cuándo usar
Personas humanas que acceden a la consola. Evitar para aplicaciones.
Trampa de examen
Access keys expuestas = credenciales de larga duración. Mayor riesgo.
IAM Groups
Colección de usuarios IAM. Las políticas adjuntas al grupo se aplican a todos sus miembros.
Cuándo usar
Organizar usuarios por función (Developers, Admins, Ops) y asignar permisos en masa.
Trampa de examen
Los grupos NO pueden ser miembros de otros grupos. Sin anidamiento.
IAM Roles
Identidad temporal que servicios, aplicaciones o cuentas pueden asumir. Sin credenciales permanentes.
Cuándo usar
EC2, Lambda, ECS. También para acceso cross-account o federación de identidades.
Trampa de examen
SIEMPRE preferir roles sobre access keys para servicios AWS. Son la respuesta correcta.
Las políticas son documentos JSON que definen permisos. Cada declaración (Statement) contiene: Effect (Allow/Deny), Action (ej: s3:GetObject), Resource (ARN del recurso), y opcionalmente Condition.
AWS Managed Policies
Creadas y mantenidas por AWS. Ej: AdministratorAccess, ReadOnlyAccess. No se pueden modificar.
Customer Managed Policies
Creadas por ti. Reutilizables en múltiples identidades. Versionadas — puedes revertir cambios.
Inline Policies
Embebidas directamente en una identidad (1:1). Se eliminan con la identidad. Evitar — difícil de auditar.
Resource-based Policies
Adjuntas al recurso (S3 bucket policy, SQS policy). Permiten acceso cross-account sin asumir rol.
Estructura JSON de una política
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::mi-bucket/*",
"Condition": {
"StringEquals": {"aws:RequestedRegion": "us-east-1"}
}
}
]
}AWS Organizations permite gestionar múltiples cuentas AWS desde una cuenta maestra. Las Service Control Policies (SCPs) se aplican a OUs y cuentas para limitar los permisos posibles.
SCPs — qué son y qué NO son
No otorgan permisos — solo los limitan (son el techo máximo)
No afectan al usuario root de la cuenta miembro
No reemplazan las IAM Policies en la cuenta
Definen el límite MÁXIMO de permisos posibles para una cuenta
Se heredan en cascada: OU padre → OU hijo → cuentas miembro
Para que una acción sea posible, debe estar permitida en SCP Y en IAM
Un Permission Boundary es una política adjunta a un usuario o rol que define el máximo de permisos que esa entidad puede tener, independientemente de las políticas asignadas.
Cómo funciona — intersección de permisos: el permiso efectivo es la intersección entre lo que permite la Identity Policy y lo que permite el Permission Boundary.
Caso de uso principal
Delegar administración con límites seguros. Ej: permitir a desarrolladores crear roles IAM para sus funciones Lambda, pero con un boundary que evite que esos roles tengan más permisos que el propio desarrollador.
IAM Identity Center (SSO)
Gestión centralizada de acceso SSO con IAM Identity Center para múltiples cuentas de AWS Organizations y aplicaciones SaaS.
Cuándo usar
Para organizaciones con múltiples cuentas. Reemplaza gestión manual de usuarios por cuenta.
Cognito User Pools
Directorio de usuarios para aplicaciones web/móviles. Soporta OAuth 2.0, OIDC, SAML.
Cuándo usar
Aplicaciones B2C con usuarios externos. Gestión de registro, login, MFA para end-users.
Cognito Identity Pools
Entrega credenciales AWS temporales a usuarios autenticados (de User Pool u otro IdP).
Cuándo usar
Aplicaciones móviles que necesitan acceso directo a servicios AWS (S3, DynamoDB).
Usa roles, no access keys
EC2, Lambda, ECS, EKS: siempre asignar un IAM Role al servicio. Access keys en código = error de arquitectura en el examen.
Deny explícito siempre gana
Un Deny en cualquier política (Identity, Resource, SCP) anula todos los Allow. No importa cuántas policies den Allow.
SCPs limitan, no otorgan
Aunque el SCP permita s3:*, si el usuario no tiene una policy IAM con ese permiso, no puede acceder. SCP es el techo, IAM es el piso.
IAM es global
Los usuarios, grupos, roles y políticas existen a nivel de cuenta, no de región. Un rol creado en us-east-1 se puede usar en eu-west-1.
Prefiere Customer Managed Policies
Son reutilizables, versionadas y más fáciles de auditar que Inline Policies. AWS Managed son OK pero no se pueden customizar.
Visualiza cómo AWS evalúa cada solicitud a la API paso a paso.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa tiene AWS Organizations con varias cuentas. El equipo de seguridad aplica un SCP a la OU de producción que deniega ec2:TerminateInstances. Un desarrollador en esa OU tiene una IAM policy con Allow en ec2:*. ¿Puede terminar instancias EC2?
Pon a prueba lo que aprendiste con preguntas originales del examen SAA-C03.
Iniciar simulacro SAA-C03Sin límite de simulacros con plan Pro
Inicia sesión para llevar tu progreso.