Identidad, control de acceso y protección de datos

La seguridad es el dominio individual más pesado del CLF-C02: el Dominio 2 carga el 30% del contenido puntuado, y sus dos tareas de acceso (2.3 "Identificar las capacidades de gestión de acceso de AWS" y 2.4 "Identificar componentes y recursos para la seguridad") son las más fiablemente evaluadas de todo el examen. El planteamiento de la propia AWS parte de una frase incómoda sobre el usuario root: este tiene "acceso completo a todos los servicios y recursos de AWS". Todo lo demás de esta lección, MFA, roles, Identity Center, privilegio mínimo, grupos de seguridad, WAF, cifrado, existe para asegurar que esa frase nunca se convierta en un incidente.

En esta lección vas a:

• proteger el usuario root: límites de dispositivos MFA, la regla de 35 días, sin claves de acceso de root y las tareas que solo root puede hacer;
• construir IAM a partir de sus cuatro objetos: usuarios, grupos, roles y políticas;
• separar políticas basadas en identidad de las basadas en recurso y ejecutar la lógica de evaluación: deny explícito, unión, techos, entre cuentas;
• elegir roles frente a usuarios desde el enunciado de la pregunta: entre cuentas, perfiles de instancia EC2, federación, ID externo;
• situar correctamente IAM Identity Center (SSO de la plantilla), Cognito (identidad del cliente) y Directory Service (AD empresarial);
• elegir una opción de autenticación: passkeys/FIDO, TOTP virtual, TOTP de hardware, claves de acceso, credenciales temporales de STS;
• comparar grupos de seguridad y NACL en alcance, reglas, estado y valores por defecto;
• decidir entre AWS WAF, Shield Standard, Shield Advanced y Firewall Manager: con aritmética real de factura;
• proteger los datos en reposo y en tránsito y seguir el cifrado de sobre de KMS y los tres tipos de clave;
• describir en una línea cada servicio de detección en alcance y ejecutar una lista de verificación de privilegio mínimo;
• estudiar cuatro casos de estudio de seguridad y cumplimiento publicados por AWS: política de red centralizada, acceso basado en identidad, controles FedRAMP heredados y autorización más rápida;
• seguir las actualizaciones de guía y herramientas de 2026 que tocan IAM, el alcance de las políticas y las herramientas de seguridad: cada punto con fuente y fecha;
• practicar con 12 preguntas estilo examen más cuatro comprobaciones interactivas.

---

1. La cuenta root: una identidad, alcance ilimitado

1.1 Qué es root

Hay exactamente una identidad root por cuenta de AWS, una dirección de correo más una contraseña, y AWS documenta que tiene "acceso completo a todos los servicios y recursos de AWS", incluida la facturación. No se puede eliminar, no se puede limitar con una política de IAM dentro de su propia cuenta, y omite las comprobaciones sin MFA en cuanto se usa. Por eso la tarea 2.3 del Dominio 2 lista la "importancia de proteger la cuenta del usuario raíz de AWS" como conocimiento e "identificar las tareas que solo el usuario raíz de la cuenta puede realizar" como habilidad: el examen quiere que sepas tanto por qué importa root como qué tareas lo requieren de verdad.

1.2 Tareas que solo el usuario root puede realizar

La lista es corta, memorable y evaluable; estas son las respuestas a "¿qué acción requiere el usuario root?":

• cambiar el correo, la contraseña o las claves de acceso de la propia identidad root (cuentas independientes);
• cerrar o reabrir una cuenta independiente;
• restaurar los permisos de un usuario de IAM: la recuperación del bloqueo del último administrador;
• activar el acceso de IAM a la consola de facturación;
• ver ciertas facturas fiscales;
• registrarse en el EC2 Reserved Instances Marketplace;
• habilitar S3 MFA Delete;
• editar o eliminar una política de recurso de S3 o SQS que niega a todos los principales;
• registro en GovCloud y claves de root; vincular una cuenta de Amazon Mechanical Turk.

Todo lo demás en el examen, crear usuarios de IAM, adjuntar políticas, arrancar EC2, escribir políticas de bucket, restablecer la contraseña de un colega, lo hace una identidad administrativa, nunca root.

1.3 Ejemplo E1: endurecimiento de root el día 1, paso a paso

Se abre una cuenta de producción nueva. La secuencia de endurecimiento siguiente usa solo límites verificados:

• 📚 ¿Sabías que…? La página de mejores prácticas de usuarios root de AWS recomienda la aprobación multipersona para root: un grupo guarda la contraseña de la cuenta, otro grupo distinto guarda el dispositivo MFA, de modo que ningún empleado individual pueda actuar como root en solitario. La misma página limita MFA a ocho dispositivos por usuario root y te dice que registres el MFA de root dentro de los 35 días del primer inicio de sesión: dos números que al examen le gusta devolverte (en octubre de 2026; verifica el estado vigente antes de usarlos).

---

2. Piezas de IAM: usuarios, grupos, roles y políticas

2.1 Los cuatro objetos, exactamente

Un rol tiene dos mitades y ambas son obligatorias: la política de permisos responde qué puede hacer la sesión, y la política de confianza (una política basada en recurso adjunta al rol) responde quién puede asumirlo. Una política de permisos perfectamente escrita con una política de confianza que no nombra a nadie es inútil: es una puerta cerrada con un cartel que dice "solo empleados" y sin empleados listados en él.

2.2 Políticas basadas en identidad frente a basadas en recurso

Las políticas gestionadas por AWS son puntos de partida amplios mantenidos por AWS (funciones de trabajo como administración de solo lectura). Las políticas gestionadas por el cliente son las que escribes y refinas: el estado final de privilegio mínimo. Las políticas en línea están incrustadas en un principal y se eliminan con él, lo que las útiles para permisos puntuales y peligrosas como valor por defecto.

2.3 Cómo evalúa AWS una petición: gana el deny explícito

El orden documentado de AWS, comprimido a los cuatro movimientos que aparecen en el examen:

1. Autenticar al invocador (¿quién es este?).
2. Recopilar cada política aplicable: basada en identidad y basada en recurso, más SCPs, RCPs, límites de permisos y políticas de sesión.
3. Cualquier Deny explícito en cualquier lugar gana. AWS "primero comprueba todas las políticas en busca de un Deny": un solo deny, en cualquier documento aplicable, vence a todo allow.
4. En caso contrario, calcula la unión de los allows basados en identidad y en recurso, y luego lo interseca con el techo: los límites de permisos, los SCPs y los RCPs deben permitir todos (una intersección). Los SCPs no conceden nada: solo filtran lo que una identidad dentro de la cuenta podría hacer de otro modo.

2.4 Ejemplo E2: permisos efectivos de John (tres capas)

La política de identidad de John permite s3:Get* en reports/*. La política del bucket reports dice Deny s3:* cuando aws:SecureTransport es false. El SCP de la cuenta dice Deny s3:* fuera de la Región base.

Cuenta las capas: un allow, dos denies, tres tipos de política, y lee la dirección de cada petición antes de elegir. Observa qué pasaría si se quitara la política de identidad: (a) se convierte en un deny implícito, de modo que quitar un privilegio es una mitigación real, no una formalidad.

2.5 Límites de permisos y las herramientas de privilegio mínimo

Un límite de permisos (permissions boundary) es una política gestionada que fija el máximo que una política de identidad puede conceder. Por sí mismo no concede nada: su caso de uso en el examen es la delegación segura: dejar que un desarrollador escriba su propia política de identidad, pero acotarla con un límite para que nunca pueda exceder, digamos, solo-lectura más un bucket de sandbox. El conjunto de herramientas de estrechamiento para el privilegio mínimo es:

• partir de una política de función de trabajo gestionada por AWS;

• refinar con IAM Access Analyzer (genera políticas a partir de la actividad de CloudTrail, valida acceso externo/público, previsualiza exposición entre cuentas);

• comprobar la información de último acceso para borrar permisos que nadie usa.

• 📚 ¿Sabías que…? Un grupo no puede usarse como Principal en ninguna política de AWS: adjuntas una política a un grupo, pero nunca puedes permitir a un grupo en una política de bucket o de confianza de rol; debes nombrar a sus usuarios o, mejor, a un rol. Los grupos tampoco pueden anidarse, y en IAM no existe un grupo de usuarios por defecto (en octubre de 2026).

---

3. Roles frente a usuarios: la decisión que el examen repite

3.1 La tabla de casos de uso

Aritmética de sesiones que vale la pena memorizar: las sesiones de AssumeRole duran hasta 43.200 segundos = 12 horas, mientras que el encadenamiento de roles (asumir un segundo rol desde un primero) está limitado a 1 hora: una diferencia de 12×. Durante una sesión, los permisos del rol sustituyen a los del invocador durante ese tiempo.

3.2 Ejemplo E3: el rol de auditoría entre cuentas

Un auditor en la cuenta 1111 necesita acceso de solo lectura a la cuenta 2222. Dos documentos, ambos obligatorios:

Cualquiera de las dos políticas por sí sola falla: confianza sin concesión de identidad da "no estás autorizado"; concesión de identidad sin confianza da "no estás autorizado para realizar sts:AssumeRole". La sesión es temporal (1 hora por defecto, hasta 12 horas): nada que filtrar, nada que rotar, y el acceso desaparece cuando se revoca la confianza del rol.

3.3 Ejemplo E4: el perfil de instancia EC2, cero claves embarcadas

Una aplicación en EC2 debe leer s3://photos. En lugar de copiar una clave de acceso en la AMI:

1. Crea el rol Get-pics cuya política de confianza permite al servicio ec2.amazonaws.com.
2. Adjunta una política de permisos que permita s3:GetObject solo en ese bucket.
3. Adjunta el rol a la instancia mediante un perfil de instancia.
4. El SDK lee credenciales temporales del servicio de metadatos de la instancia y las actualiza antes de que caduquen: el desarrollador nunca ve un secreto.

Si la instancia se ve comprometida, el atacante hereda exactamente un permiso en exactamente un bucket: el radio de impacto es el documento de política, no la cuenta de AWS de la empresa. Contrasta con la respuesta del usuario de IAM: una clave de acceso horneada en una AMI es una credencial sin caducidad, sin frontera de alcance más allá de su política, y un hábito que el examen marca como incorrecto.

• 📚 ¿Sabías que…? El encadenamiento de roles merece su propio mnemotécnico: 12 horas para un AssumeRole simple, 1 hora para uno encadenado (43.200 s frente a 3.600 s, en octubre de 2026). AWS limita el encadenamiento precisamente porque cada salto multiplica la probabilidad de que una sesión obsoleta sobreviva a la persona que la inició.

---

4. IAM Identity Center: la respuesta para la plantilla

AWS Single Sign-On se renombró AWS IAM Identity Center el 26 de julio de 2022, y el examen todavía te premia por conocer ambos nombres. Identity Center es el inicio de sesión único de la plantilla de AWS: los empleados obtienen un inicio de sesión que abre muchas cuentas de AWS y aplicaciones de AWS, con permisos entregados mediante conjuntos de permisos: el paquete con nombre de permisos de AWS aplicado a un usuario o grupo, sin claves de largo plazo.

El patrón a memorizar: 12 cuentas, un inicio de sesión, sin usuarios de IAM → IAM Identity Center. La propia redacción de mejores prácticas de AWS es "Exigir que los usuarios humanos usen federación" y prefiere "MFA resistente al phishing como passkeys y llaves de seguridad": Identity Center es la forma en que esa recomendación escala más allá de un puñado de cuentas.

---

5. Amazon Cognito: identidad del cliente a profundidad de examen

Cognito es la opción de identidad del cliente (CIAM), y AWS la describe como tres cosas en un servicio: "un directorio de usuarios, un servidor de autenticación y un servicio de autorización". Está a una altitud distinta de IAM: los usuarios de tu aplicación no son usuarios de IAM y nunca ven la consola de AWS.

La profundidad de examen se detiene exactamente ahí: sabe que los user pool autentican, que los identity pool autorizan el acceso a AWS, que las credenciales de AWS son temporales, y que Cognito es para clientes mientras IAM Identity Center es para la plantilla. Los temas más profundos (personalización de la UI alojada, triggers de lambda, funciones de seguridad avanzadas) no es lo que pregunta una cuestión de practitioner.

---

6. Opciones de autenticación y MFA

6.1 Las cinco formas de demostrar quién eres

La redacción de mejores prácticas de AWS que debes reconocer: "Exigir que los usuarios humanos usen federación" y usar "MFA resistente al phishing como passkeys y llaves de seguridad". La opción trampa recomienda MFA por SMS: AWS terminó el soporte para habilitar la autenticación multifactor por SMS en IAM, así que cualquier respuesta que diga "habilitar MFA por SMS en el usuario root" es incorrecta.

⚠️ Dos números de credenciales, dos trampas. Primero, el MFA por SMS no es una opción de IAM: los factores admitidos son passkeys/llaves de seguridad FIDO (resistentes al phishing y recomendados), autenticador virtual (TOTP) y TOTP de hardware: así que "asegurar al usuario root con un código SMS" es siempre incorrecto, aunque un user pool de Cognito pueda seguir enviando códigos SMS a los usuarios de tu aplicación. Segundo, dos es el techo de claves de acceso por usuario de IAM y cero es la recomendación para root; un "arreglo" que acuña una tercera clave, o una clave de acceso de root "solo para este script", responde a la pregunta equivocada.

6.2 Dónde viven los secretos

La tarea 2.3 nombra explícitamente el almacenamiento de credenciales: AWS Secrets Manager y AWS Systems Manager Parameter Store (SecureString). Las claves codificadas en duro en un repositorio, en una AMI o en variables de entorno de una Lambda pública son el anti-patrón que el examen evalúa por inversión: la respuesta correcta siempre recupera un secreto en tiempo de ejecución desde uno de esos dos servicios, o evita el secreto por completo usando un rol.

6.3 Ejemplo E5: contar las credenciales en una cuenta

Una configuración de cuenta única tiene: root (0 claves de acceso), 6 usuarios de IAM con 2 claves de acceso cada uno, 10 roles, 3 conjuntos de permisos en Identity Center.

La pregunta de auditoría se escribe sola: existen 12 secretos de largo plazo y solo 2 personas los necesitan. La remediación no es "añadir MFA": es sustituir a los usuarios por grupos y roles de Identity Center, borrar las claves sin uso y mantener los pares restantes en un calendario de rotación.

• 📚 ¿Sabías que…? El techo de dos claves de acceso por usuario es deliberado: tener la clave uno mientras la clave dos sigue viva te permite rotar sin tiempo de inactividad (actualiza la aplicación y luego borra la clave antigua). AWS muestra la clave secreta exactamente una vez: después, la única recuperación es crear un par de claves nuevo, y por eso "ver de nuevo la clave secreta antigua" nunca es una opción válida.

---

7. Grupos de seguridad frente a NACL

Ambos son los filtros de paquetes de la VPC, ambos son gratuitos (en octubre de 2026), y difieren en cuatro ejes que el examen evalúa sin descanso.

Dos consecuencias se derivan directamente de la columna de estado: con un grupo de seguridad con estado abres 443 de entrada y las respuestas fluyen de vuelta automáticamente; con una NACL sin estado debes permitir también los puertos de vuelta efímeros de entrada, o la conexión nunca se completa. Y ninguno de los dos dispositivos filtra DNS, DHCP, el servicio de metadatos de la instancia, los metadatos de tareas de ECS ni Time Sync: esos los bypasean por diseño.

7.1 Los valores por defecto no son "seguros"

• El grupo de seguridad por defecto permite todo el tráfico saliente y el entrante solo desde sí mismo: usable, no seguro.
• La NACL por defecto permite todo el tráfico de entrada y salida, más reglas DENY con * que siempre están al fondo de la lista: permisiva por defecto, con el catch-all de denegación disponible para un bloqueo rápido.

Ninguno de los dos valores por defecto responde a "cómo restringo esto", y "añadir una regla de deny al grupo de seguridad" es siempre incorrecto: los grupos de seguridad no tienen reglas de denegación: usa una NACL, o niega en la capa de IAM/política de bucket.

7.2 Ejemplo E6: defensa de red en capas

Una aplicación de tres capas orientada a Internet, montada a partir de comportamiento verificado:

El modelo mental: NACL = el portero de la subred con una lista negra; grupo de seguridad = el firewall de la instancia con solo una lista de invitados; WAF = el inspector de la capa de aplicación; Shield = el paraguas anti-DDoS.

• 📚 ¿Sabías que…? Las reglas de grupo de seguridad pueden referenciar otros grupos de seguridad, y así funciona el patrón por capas de arriba sin codificar bloques CIDR, y por eso mover una capa de aplicación a una subred nueva no requiere editar ninguna regla. Las NACL, en cambio, están ligadas a la subred y basadas en IP por naturaleza (en octubre de 2026; aplican cuotas por VPC y por SG, verifica el estado vigente antes de usarlas).

---

8. AWS WAF, AWS Shield y AWS Firewall Manager

Tres servicios, tres altitudes. Confundirlos cuesta varias preguntas, porque cada uno tiene una identidad de una frase:

La capacidad de WAF se mide en Web ACL Capacity Units (WCUs); las reglas pueden ser personalizadas, AWS Managed Rules o grupos de reglas de Marketplace, más conjuntos de IP/regex y reglas basadas en tasa. Shield Advanced también incluye hasta 50.000 millones de peticiones WAF al mes por ID de pagador y protección del coste por DDoS (reembolso de cargos de escalado causados por un ataque).

8.1 Ejemplo E7: la factura de WAF

AWS publica su propio ejemplo resuelto, y la aritmética se generaliza:

Observa qué no aparece en la factura: los grupos de seguridad y las NACL son gratuitos, así que "añadir una regla de grupo de seguridad" es la respuesta de coste cuando la pregunta trata sobre filtrar tráfico que nunca llega a un conjunto de reglas HTTP.

8.2 Ejemplo E8: aritmética de Shield Advanced

La prueba de formulación es fiable: "protección DDoS gratuita y automática" → Shield Standard; "detener la inyección SQL en este ALB" → WAF; "aplicar este conjunto de reglas a cada cuenta de la organización" → Firewall Manager.

---

9. Protección de datos: en reposo, en tránsito y KMS

9.1 Las dos direcciones

Opciones de cifrado de S3 a profundidad de examen: SSE-S3 (predeterminado, gratuito), SSE-KMS (cargos por petición, más una pista de auditoría por uso en CloudTrail), DSSE-KMS (doble capa), SSE-C (tú suministras la clave) y cifrado del lado del cliente. Haz cumplir el tránsito con una política de bucket o un SCP que niegue aws:SecureTransport = false: el deny de la §2.4, aplicado a la protección de datos.

9.2 KMS: claves y cifrado de sobre

AWS Key Management Service mantiene las claves dentro de módulos de seguridad de hardware (HSM) validados FIPS 140-3 Security Level 3: las claves se generan allí y nunca salen de esa frontera sin cifrar. Como llamar al HSM por cada byte sería absurdo, KMS usa el cifrado de sobre: "cifrar la clave de datos bajo otra clave".

Rotar la clave nunca vuelve a cifrar tus datos en bloque: la clave raíz solo re-envuelve la clave de datos, que es la razón práctica por la que existe el cifrado de sobre.

9.3 Ejemplo E9: cifrado de sobre en un objeto de 1 GB

1. Tu aplicación llama a KMS GenerateDataKey con una clave gestionada por el cliente. KMS devuelve una clave de datos en texto plano y la misma clave cifrada bajo la clave KMS.
2. La aplicación cifra el objeto de 1 GB con la clave de datos en texto plano en memoria; la clave en texto plano se descarta.
3. La clave de datos envuelta se guarda junto al cifrado. KMS nunca ve el objeto; el HSM nunca exporta la clave raíz.
4. Para leer el objeto más tarde, la aplicación envía solo la clave envuelta de vuelta a KMS (Decrypt), recibe la clave en texto plano y descifra localmente.
5. Si mañana rotas la clave KMS, solo cambia el envolvimiento del paso 4: el objeto de 1 GB no se toca.

• 📚 ¿Sabías que…? Las claves KMS gestionadas por AWS ahora rotan aproximadamente cada 365 días, un cambio hecho en mayo de 2022, cuando el intervalo se acortó de tres años, y no llevan cuota mensual de clave (las cuotas por uso siguen aplicando, en octubre de 2026). La clave gestionada por el cliente es el único tipo que te da control de la política de clave, habilitar/deshabilitar, eliminación programada y rotación personalizada, y por eso "qué clave me da control total" casi siempre significa gestionada por el cliente, no "la que yo creé" frente a "la que creó AWS".

---

10. Detección de amenazas, auditoría y postura: líneas de una línea en alcance

La tarea 2.4 del Dominio 2 te pide describir funciones de seguridad e identificar "servicios para identificar problemas de seguridad". Cada fila de abajo está en la lista en alcance del CLF-C02 o en un enunciado de tarea del Dominio 2: nada más.

Mnemotécnico:

• GuardDuty detecta
• Inspector analiza
• Macie encuentra datos sensibles
• Detective explica
• Security Hub agrega
• Trusted Advisor asesora
• CloudTrail registra
• Config recuerda
• Artifact certifica

• 📚 ¿Sabías que…? El historial de eventos de CloudTrail es gratuito y automático durante los últimos 90 días de eventos de administración en cada cuenta: no tienes que crear un rastro para responder "quién terminó mi instancia el mes pasado". Un rastro hacia un bucket S3 privado con validación de archivos de registro es la mejora que te da el registro completo y a prueba de manipulaciones que exige la lista de mejores prácticas (en octubre de 2026).

---

11. La lista de verificación de mejores prácticas de privilegio mínimo

11.1 Cinco grupos de hábitos

11.2 Ejemplo E10: puntuar una cuenta frente a la lista

---

Casos Reales

AWS publica cómo se ven estos patrones en producción. Cada cifra de abajo es afirmada por el cliente o por AWS y no auditada, citada con su fuente para que puedas verificarla: el punto evaluable es el patrón (qué control se centralizó, qué modelo de identidad reemplazó a cuál, qué cifra se movió), no la cifra de marketing.

Caso A, athenahealth: seguridad de red centralizada en 120 cuentas

Lección de examen: la cifra que recordar no es 95%, son 120 cuentas y ocho personas. La respuesta del Dominio 2 a "¿cómo haces cumplir un control en todas partes" es siempre centralizar la política y compartirla (RAM, Firewall Manager, SCPs, un CloudTrail de organización), nunca "entrar en cada cuenta". Observa que AWS Network Firewall está fuera de alcance para las preguntas de selección de servicios del CLF-C02 en la guía actual, conoce el patrón de centralización, selecciona el servicio en alcance.

Caso B, Avalon Healthcare Solutions: acceso basado en identidad en lugar de VPN

Lección de examen: esta es la forma de Zero Trust que el Dominio 2 premia: verificar la identidad, conceder de forma estrecha y dejar de tratar a la red como la frontera. AWS Verified Access no está en la lista de seguridad en alcance del CLF-C02, así que aparece solo como distractor: las selecciones en alcance para este patrón son IAM Identity Center (federación de la plantilla), Cognito (identidad del cliente) y roles de IAM entre cuentas.

Caso C, Smartsheet Gov: FedRAMP ready en menos de 90 días

Lección de examen: la cifra que retener es <90 días frente a 12 to 18 meses: una historia de evidencia, no de selección de servicios. FedRAMP es una autorización gubernamental, no un producto de AWS: AWS suministra GovCloud (US) y los controles heredados, el cliente obtiene el ATO. Cuando una pregunta pregunta de dónde viene el papeleo de auditoría, la respuesta en alcance es AWS Artifact; cuando pregunta quién parchea el hipervisor, la respuesta es el modelo de responsabilidad compartida.

Caso D, Socure: 46+ controles FedRAMP heredados de GovCloud

Lección de examen: 46 heredados, cero delegados. Los controles heredados son todo el argumento a favor del modelo de responsabilidad compartida: AWS cubre la plataforma, tú sigues siendo dueño de la identidad, el privilegio mínimo, el cifrado y la configuración. Las selecciones evalables detrás de este párrafo son KMS, CloudTrail, Config, GuardDuty, Security Hub, IAM y AWS Artifact para la evidencia misma: no las herramientas complementarias nombradas en el blog.

• 📚 ¿Sabías que…? La herencia corta en ambos sentidos en estas dos historias: Smartsheet Gov alcanzó FedRAMP ready en menos de 90 días donde AWS dice que el proceso puede durar 12 to 18 meses, y Socure contó más de 46 controles FedRAMP heredados, y sin embargo ambos seguían siendo dueños de su propio IAM, sus claves y su configuración. Precisamente por eso el modelo de responsabilidad compartida tiene dos columnas, y por eso "AWS se ocupa de la seguridad, así que me salto el MFA" nunca es la respuesta (AWS Public Sector Blog, 29 de ago de 2019 y 14 de nov de 2024; cifras publicadas por el cliente).

Qué comparten los casos de seguridad

Actualizaciones de 2026 (en octubre de 2026)

• 📚 ¿Sabías que…? El PDF actual de la guía del examen no lleva número de versión en absoluto, solo "Copyright © 2026", mientras que el único artefacto fechado que AWS jamás publicó es la guía Version 1.0 CLF-C02 de la era de lanzamiento. La cadena uiVersion=2024.10 visible en las URL de AWS Docs es la versión de la plantilla del sitio de documentación, no una revisión de la guía, y la página en alcance advierte que su lista es "no exhaustiva y sujeta a cambios" (los tres verificados en 2026-10).

---

Preguntas de Práctica (Practice Questions)