Gobernanza, Lake Formation y protección de PII

El Dominio 4 vale el 18% del contenido puntuado, y su última tarea, Comprender la privacidad y la gobernanza de los datos, es donde el examen DEA-C01 deja de preguntar «¿puedes mover los datos?» y empieza a preguntar «¿quién puede ver qué fila, en qué Región y cómo lo demostrarías un año más tarde?». Dos servicios soportan casi todo ese peso: AWS Lake Formation, que decide qué puede ver un principal dentro del lago, y Amazon Macie, que encuentra los datos sensibles que se supone que debes proteger. Ambos aparecen rutinariamente mal tipificados en los exámenes de práctica, Lake Formation como sustituto de IAM y Macie como herramienta de bloqueo, y ambos malentendidos cuestan preguntas.

En esta lección vas a:

• separar IAM de Lake Formation y defender la regla de «dos puertas, ambas deben abrirse» que decide la mayoría de preguntas de acceso al lago;
• leer la anatomía de permisos a nivel de catálogo, base de datos, ubicación S3, LF-Tag y enlace de recurso;
• construir controles a nivel de columna, de fila y de celda con los filtros de datos de Lake Formation, incluidos sus límites de PartiQL;
• aplicar LF-Tags (control de acceso basado en atributos): predefinir, asignar, heredar, encadenar y la semántica de concesión AND/OR;
• compartir datos entre cuentas y entre Regiones con AWS RAM, enlaces de recurso y concesiones de destino separadas;
• razonar sobre las tablas gobernadas, su finalización de soporte el 31 de diciembre de 2024 y el patrón de versiones de catálogo verde/azul;
• situar Glue, Athena, Spectrum, QuickSight, EMR y Redshift frente al cumplimiento de Lake Formation, motor a motor;
• operar Amazon Macie: descubrimiento automatizado, trabajos de descubrimiento, identificadores gestionados frente a personalizados, hallazgos, severidad y automatización con EventBridge, y nunca llamarlo prevención;
• conceder intercambio de datos en Redshift mediante datashares y reconstruir el linaje de datos con SageMaker ML Lineage Tracking y el versionado del catálogo de Glue;
• ejecutar privacidad a profundidad de examen: etiquetado de PII, residencia de datos, supresión, auditoría con CloudTrail y responsabilidad compartida;
• estudiar cuatro casos de clientes de AWS, un recuadro de actualizaciones de octubre de 2026 con su fuente y 14 preguntas estilo examen más tres comprobaciones interactivas.

---

1. El mapa de gobernanza del Dominio 4: las ocho habilidades que responde esta lección

1.1 Las declaraciones de tarea, textualmente

Dos habilidades vecinas se dirigen deliberadamente a otras lecciones: 4.5.4 (AWS Config para cambios de configuración) aparece aquí solo donde se contrasta con CloudTrail, y 4.5.6 (proyectos de Amazon SageMaker Catalog) la nombra la guía pero no es un constructo de Lake Formation.

1.2 Las personas: quién puede conceder qué

La fila del administrador de IAM es el hecho sobre personas más examinado de esta sección: la pericia en identidad no otorga autoridad sobre el data lake. Un ingeniero que puede editar cualquier política IAM de la cuenta sigue sin poder conceder SELECT sobre una tabla de Lake Formation hasta que sea administrador del data lake.

• 📚 ¿Sabías que…? Las comprobaciones de permisos de Lake Formation son gratis; se factura por los servicios integrados que ejecutas (Athena, Spectrum, Glue) y por la Lake Formation Storage API, que factura bytes escaneados redondeados al megabyte siguiente con un mínimo de 10 MB por solicitud (página de precios de Lake Formation, consultada en octubre de 2026). Así que la capa de gobernanza es barata para conceder de más financieramente y cara para conceder de más políticamente, y por eso el examen la prueba sobre corrección, no sobre coste.

1.3 La división del trabajo en una tabla

---

2. La distinción del examen: Lake Formation frente a IAM para el acceso al lago S3

2.1 Dos puertas, ambas deben abrirse

AWS enuncia la regla en una frase, y toda pregunta de acceso al lago es una variación de ella:

«Cuando un principal hace una solicitud para acceder a recursos del Catálogo de datos o a los datos subyacentes, para que la solicitud tenga éxito debe superar las comprobaciones de permisos de tanto IAM como Lake Formation».: Visión general de los permisos de Lake Formation (consultada en octubre de 2026)

Tres corolarios salen directamente de esa imagen, y cada uno es una pregunta:

1. Una concesión de Lake Formation sin IAM falla. El principal todavía necesita glue:* en las APIs del catálogo, lakeformation:GetDataAccess para las credenciales entregadas y los permisos propios del motor.
2. IAM a solas no puede expresar el grano fino. Ninguna política de identidad puede decir «solo las filas donde region = 'EU'» ni «todas las columnas excepto ssn»: eso vive exclusivamente en los filtros de datos de Lake Formation.
3. No registrado significa no gobernado. Los buckets de resultados de Athena, los prefijos no registrados y todo lo que esté fuera del catálogo lo deciden IAM y S3 por sí solos, y Lake Formation no se aplica al escribir objetos (documentación de seguridad de Athena, consultada en octubre de 2026).

2.2 IAM frente a Lake Formation, lado a lado

2.3 El valor por defecto que hace parecer rotas las concesiones

«De forma predeterminada, Lake Formation establece el permiso Super en todas las bases de datos y tablas del Catálogo de datos para un grupo llamado IAMAllowedPrincipals … todos los principales de tu cuenta tendrán acceso … a través de las políticas de principal de IAM para AWS Glue».: Referencia de permisos de Lake Formation (consultada en octubre de 2026)

Hasta que revocas ese grupo (o activas el modo de acceso híbrido), el catálogo se comporta como si Lake Formation no estuviera allí: cada principal de IAM de la cuenta lee cada tabla y tus concesiones cuidadosamente escritas parecen no cambiar nada. El modo de acceso híbrido divide la cuenta en dos: los principales que han optado deben superar tanto Lake Formation como IAM, mientras que los principales que no han optado siguen gobernados solo por IAM.

2.4 Ejemplo resuelto E1: «mis concesiones no hacen nada» en cuatro comprobaciones

Un analista informa de que una revocación no tuvo efecto. Recorre la lista en este orden:

---

3. El modelo de permisos: base de datos, tabla, columna, fila

3.1 Conjuntos de permisos por capa de recurso

Dos reglas estructurales importan más que la propia lista:

• ALL-tables implica DESCRIBE de la base de datos: conceder sobre «todas las tablas» revela necesariamente que la base de datos existe, y esta implicación no se cumple en las concesiones por atributo (LF-Tag).
• Revocar Super no revoca todo. Un principal puede quedarse con SELECT e INSERT corrientes tras quitar Super: «revocar Super» no es sinónimo de «revocar acceso».

3.2 Filtros de datos: la combinatoria columna/fila/celda

Un filtro de datos por tabla combina una especificación de columna (lista de inclusión, lista de exclusión o el comodín de todas las columnas) con un predicado de fila opcional en un subconjunto de PartiQL, o con AllRowsWildcard. AWS enuncia la regla de combinación directamente:

«El comodín “todas las columnas” + filtro de fila = seguridad a nivel de fila solamente. Lista de inclusión/exclusión de columnas específicas + “todas las filas” = seguridad a nivel de columna solamente. Columnas específicas y un filtro de fila = seguridad a nivel de celda».: Filtrado de datos (consultado en octubre de 2026)

Restricciones que debes poder citar:

3.3 Aritmética de predicados: cuando se encuentran dos reglas

• Un principal y su propio grupo de IAM: los filtros de fila se unen: el usuario ve el más amplio de los dos.
• Una concesión a una cuenta externa intersectada con una concesión directa: intersección: gana el resultado más estrecho.
• Dos comodines all-rows concurrentes: prevalece el all-rows.
• Entre motores: el cumplimiento ocurre en el momento de la consulta, de modo que un filtro que Athena respeta todavía debe reimplementarse dondequiera que se lean los datos sin el cumplimiento de Lake Formation (Sección 6).

3.4 Ejemplo resuelto E2: diseñar la protección a nivel de celda para ssn

Requisito: los analistas del Reino Unido ven solo las filas de clientes del Reino Unido, y nadie con el rol de analista ve nunca la columna ssn.

Lee la aritmética de la regla: columna excluida más predicado de fila = nivel de celda; si hubiéramos usado el comodín de todas las columnas con el mismo predicado habríamos entregado solo protección a nivel de fila y habríamos filtrado ssn a cada fila del Reino Unido.

3.5 Ejemplo resuelto E3: la escalera de cuatro concesiones sobre una tabla

Lectura: la protección es una propiedad del filtro adjunto a la concesión, no de la tabla. Dos analistas que consultan la misma tabla customers pueden ver legítimamente conjuntos de columnas distintos y conjuntos de filas distintos: que es exactamente lo que significa «seguridad a nivel de celda» en este examen.

---

4. LF-Tags: control de acceso basado en atributos y la cascada

4.1 Las seis reglas de las concesiones por etiqueta (LF-TBAC)

1. Primero se predefine. Un par clave/valor no puede inventarse en el momento de la asignación: debe existir ya como LF-Tag.
2. Un valor por clave por recurso. Una tabla no puede ser a la vez classification=public y classification=restricted en la misma clave.
3. Los valores se guardan en minúsculas.
4. La herencia es direccional: «Las tablas heredan las LF-Tags de las bases de datos y las columnas heredan las LF-Tags de las tablas. Los valores heredados pueden sobrescribirse.»
5. Concede sobre la etiqueta, no sobre el objeto: GRANT SELECT ON TAGS module=Sales TO analyst_role: queda cubierta cada tabla que lleve esa etiqueta, incluidas las tablas que cree el crawler mañana.
6. Las LF-Tags no son etiquetas de IAM. La redacción de AWS es absoluta: «Las etiquetas de IAM no son lo mismo que las LF-Tags. Estas etiquetas no son intercambiables.» Se componen: ambas comprobaciones deben permitir la solicitud.

4.2 La cascada, dibujada

4.3 Semántica de las concesiones: AND entre claves, OR dentro de una clave

4.4 Ejemplo resuelto E4: concesiones con nombre frente a concesiones por etiqueta

Configuración: 3 principales analistas, cada uno necesita el mismo acceso a 3 bases de datos y 7 tablas, más un plan para añadir 50 tablas más el próximo trimestre. (Aritmética derivada: no es una cifra publicada por AWS; la estructura sigue la documentación de TBAC de Lake Formation, consultada en octubre de 2026.)

Lectura: la ruta por etiqueta colapsa 180 operaciones en 7 porque la concesión se adjunta a un atributo que los objetos nuevos heredan automáticamente. Por eso la habilidad 4.2.5 nombra la autorización por etiquetas y por atributos como respuesta a una necesidad de negocio: a escala, la diferencia no es comodidad, es si los permisos siguen siendo correctos a medida que crece el catálogo.

• 📚 ¿Sabías que…? AWS publica un resultado de cliente exactamente para esta aritmética: Integral Ad Science «redujo cientos de reglas de permiso a precisamente dos reglas» usando el control de acceso por etiquetas de Lake Formation (AWS Big Data Blog, 2021-09-23, consultado en octubre de 2026). Dos reglas no son una errata: es lo que ocurre cuando el número de objetos deja de ser el número de concesiones.

4.5 Ejemplo resuelto E5: una concesión multitenant por etiqueta

---

5. Intercambio de datos: entre cuentas, entre Regiones, tablas gobernadas, verde/azul

5.1 La secuencia productor/consumidor

Hechos codificados en ese diagrama:

• Las pilas de intercambio son o Lake Formation (RAM + enlaces de recurso) o el intercambio de catálogo heredado solo con IAM; el modo de acceso híbrido permite que ambos coexistan mientras una cuenta migra.
• El intercambio entre Regiones funciona a través de enlaces de recurso creados en la Región del consumidor: los propios permisos de Lake Formation nunca viajan.
• Una concesión directa a un principal (en lugar de un share) se une con cualquier concesión en cascada de cuenta, y solo la ve el destinatario: no puede volver a compartirla.
• El crawling entre cuentas tiene su propio orden de cuatro pasos: registrar la ubicación en la cuenta productora → conceder DATA_LOCATION_ACCESS a la función de crawler del consumidor (más GetDataAccess) → aceptar el share de RAM → crear el enlace y marcar «Use Lake Formation credentials».

5.2 Tablas gobernadas, y la fecha que debes citar

AWS construyó las tablas gobernadas como un tipo de tabla de Amazon S3 con garantías ACID entre tablas y compactación automática, para que el análisis pudiera compartir instantáneas consistentes. Después AWS anunció:

«finalización del soporte de las tablas gobernadas, con efectos a partir del 31 de diciembre de 2024, para centrarse en formatos de tabla transaccionales de código abierto como Apache Iceberg, Apache Hudi y Linux Foundation Delta Lake».: AWS Big Data Blog, 2024-10-02

Manejo en el examen: declara la obsolescencia con su fecha y responde las preguntas sobre formatos de tabla abiertos con Iceberg, Hudi o Delta Lake. Las concesiones de Lake Formation, filtros de fila y de celda incluidos, se aplican a las tablas Iceberg/Hudi/Delta catalogadas, y Lake Formation gestiona la compactación, la retención de instantáneas y el borrado de archivos huérfanos para Iceberg, mientras el motor conserva la propiedad de las sentencias DDL de escritura (VACUUM, MERGE, OPTIMIZE).

5.3 Versiones de catálogo verde/azul: un patrón, no un servicio

«Despliegue de catálogo verde/azul» no es el nombre de una característica de AWS: nada en la documentación de Lake Formation o Glue describe un servicio con ese nombre (verificado en octubre de 2026). Lo que el examen prueba realmente es si puedes ensamblar el patrón a partir de bloques de construcción verificados:

5.4 Ejemplo resuelto E6: compartir frente a copiar para un conjunto de datos de 20 TB

Lectura: la frase del examen «compartir acceso a datos en vivo … sin mover ni copiar manualmente los datos» es la pista. Cuando el primer paso de una opción es COPY, UNLOAD, rsync o «replicar el bucket», está describiendo una copia, no un intercambio.

---

6. Integración con los motores: Glue, Athena, Spectrum, QuickSight, EMR, Redshift

6.1 La matriz de cumplimiento

6.2 Ejemplo resuelto E7: qué lee realmente una consulta gobernada por Lake Formation

Una tabla Parquet de 1 TB está particionada en 12 particiones mensuales; el predicado del analista poda hasta un solo mes:

Lectura: Lake Formation decide si puede ejecutarse la consulta y qué filas/columnas vuelven; el particionado y el formato de archivo deciden cuántos bytes lee el motor; la regla de redondeo de la Storage API decide la línea de factura de Lake Formation. Tres facturas distintas, una consulta: un distractor clásico de opción múltiple.

6.3 Ejemplo resuelto E8: la misma tabla a través de dos motores

---

7. Amazon Macie: descubrimiento, no prevención

7.1 Qué es, y la frontera que no cruza

Amazon Macie es «un servicio de seguridad de datos que descubre datos sensibles mediante aprendizaje automático y coincidencia de patrones».: Qué es Amazon Macie (consultado en octubre de 2026)

7.2 Los dos motores de detección y la lista de permitidos

7.3 Trabajos, programaciones y hallazgos

7.4 El flujo del hallazgo, y dónde entra tu código

7.5 Ejemplo resuelto E9: una especificación de trabajo de Macie

7.6 Ejemplo resuelto E10: coste mensual de Macie (tarifas de ejemplo en us-east-1)

Los precios unitarios son los ejemplos publicados de AWS en us-east-1 (página de precios de Macie, consultada en octubre de 2026: verifica la tarifa vigente antes de usarla): $0.10 por bucket al mes, $0.01 por cada 100.000 objetos al mes, más cargos escalonados por el volumen de datos inspeccionado.

Lectura: el recuento de objetos es un redondeo, el recuento de buckets es pequeño y el volumen de datos inspeccionado domina. Por eso al examen le encanta la opción «escanea todo, cada hora»: es técnicamente correcta y económicamente indefendible.

7.7 Ejemplo resuelto E11: enrutar hallazgos con EventBridge

• 📚 ¿Sabías que…? Los identificadores de datos personalizados de Macie son inmutables tras su creación: AWS lo formula como «historial inmutable … para auditorías de privacidad y protección de datos» (opciones de identificador de datos personalizado de Macie, consultado en octubre de 2026). No puedes editar en silencio la expresión regular que produjo los hallazgos del trimestre pasado; creas un identificador nuevo y retiras el antiguo, que es exactamente la propiedad de auditoría que una pregunta de cumplimiento está sondeando.

---

8. Intercambio de datos en Amazon Redshift

8.1 El modelo de datashare

Redshift te permite «compartir acceso a datos en vivo entre clústeres, grupos de trabajo, cuentas de AWS y Regiones de Amazon Redshift sin mover ni copiar manualmente los datos», y «los objetos del datashare son de solo lectura para los consumidores de datos» en el modelo básico.: Visión general del intercambio de datos de Redshift (consultada en octubre de 2026)

8.2 Ejemplo resuelto E12: el ciclo de intercambio, de extremo a extremo

Lectura: están en juego tres autorizaciones y los candidatos suelen colapsarlas en una: la autorización del share, la CREATE DATABASE y el GRANT sobre objetos. Omite una cualquiera y el analista obtiene respectivamente un esquema vacío, una base de datos vacía o un error de permisos.

---

9. Linaje: seguimiento de linaje de ML de SageMaker y versionado del catálogo

9.1 Qué entiende el examen por linaje

La lista de respuestas de linaje de la guía es estrecha y vale la pena memorizarla: seguimiento de linaje de ML de SageMaker (ML Lineage Tracking), versionado del Catálogo de datos de Glue y CloudTrail. Los marcos de linaje de terceros y Amazon DataZone no están en la lista de ámbitos del DEA-C01 (a octubre de 2026), de modo que una opción construida sobre ellos no puede ser la mejor respuesta.

El seguimiento de linaje de ML de SageMaker registra un flujo de trabajo de ML «desde la preparación de datos hasta el despliegue de modelos» para que puedas reproducir ejecuciones y respaldar la gobernanza y auditoría de modelos. La jerarquía es Experimento → Prueba → Componente de prueba, y los trabajos crean las entidades de prueba automáticamente.

9.2 Las cuatro entidades y sus asociaciones

Tipos de asociación: ContributedTo, Produced, SameAs, AssociatedWith, DerivedFrom: donde SameAs es el enlace entre cuentas. Las entidades automáticas no tienen límite de cuota; las manuales sí, y una asociación no puede enlazar dos entidades de experimento.

9.3 Ejemplo resuelto E13: el presupuesto manual de linaje y la consulta de auditoría

9.4 El versionado del catálogo de Glue como señal de linaje de metadatos

El linaje a nivel de fila está fuera del alcance del catálogo, pero el linaje a nivel de esquema no:

• 📚 ¿Sabías que…? La distinción que explota el examen: CloudTrail responde «quién concedió SELECT a las 14:02» y AWS Config responde «¿cambió la política del bucket o el cifrado?». Ambas son pruebas de gobernanza, pero son preguntas distintas: una es una acción de API y la otra es el estado de configuración a lo largo del tiempo. Un enunciado que cita una marca de tiempo de un cambio de permiso apunta a CloudTrail; un enunciado que cita una regla de cumplimiento que evalúa la configuración de recursos apunta a Config.

---

10. Privacidad a profundidad de examen: PII, residencia, supresión, auditoría, cumplimiento

10.1 La canalización de PII: descubrimiento, clasificación, aplicación

La división en tres servicios es toda la habilidad: Macie descubre, Lake Formation aplica, KMS cifra. Toda opción que mueva un verbo entre ellos está comprobando si te diste cuenta.

• 📚 ¿Sabías que…? Enmascarar no es exclusivamente una habilidad de Lake Formation. EOS Group enmascaró PII con enmascaramiento dinámico de datos de Amazon Redshift (dynamic data masking) tras mover su almacén a través de AWS DMS → Amazon S3 → Amazon Redshift, y AWS reporta un 50% de reducción de costes de infraestructura con pérdida cero de datos (caso de cliente de AWS, consultado en octubre de 2026). El verbo sigue igual, enmascarar el valor sensible para este rol, pero el servicio depende del motor: filtros de datos de Lake Formation para el lago, enmascaramiento dinámico de datos de Redshift para el almacén, y ninguno de los dos es un trabajo que Amazon Macie vaya a hacer nunca.

10.2 Residencia y soberanía de los datos (habilidades 4.5.3 y 4.5.5)

10.3 Patrones de supresión (derecho al olvido)

• 📚 ¿Sabías que…? La inmutabilidad y la supresión tiran en direcciones opuestas. El lago de datos de Nasdaq respaldado por S3 combina Amazon Redshift y Spectrum con S3 Object Lock y el archivo Glacier para que los registros de mercado regulados no puedan reescribirse ni borrarse mientras dura la retención (caso de cliente Nasdaq de AWS, consultado en octubre de 2026). Una solicitud de supresión sobre un objeto bloqueado se rechaza hasta que venza el periodo de retención o se levante la retención legal: que es exactamente por lo que Object Lock aparece como la fila BLOQUEO del patrón de supresión anterior, y por qué una respuesta de cumplimiento que prometa a la vez «derecho al olvido instantáneo» y «retención WORM sobre los mismos objetos» es contradictoria.

10.4 Auditoría y cumplimiento bajo responsabilidad compartida

La última fila es el modelo de responsabilidad compartida aplicado a la privacidad: AWS aporta certificaciones y controles; el cliente aporta las decisiones de clasificación, acceso, retención y ubicación. Una opción que afirme que una certificación de AWS vuelve conforme a un cliente ha invertido el modelo.

10.5 Ejemplo resuelto E14: una barandilla de residencia para una OU analítica

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

Toda cifra siguiente es reclamada por el cliente o por AWS y no auditada, copiada de una propiedad de AWS y datada para que puedas comprobarla. El punto examinable es el patrón, qué control se aplicó, qué servicio hizo el trabajo, nunca la cifra de marketing.

Caso A, Integral Ad Science (IAS): cientos de reglas colapsadas a dos

Lee IAS como la aritmética de la Sección 4 hecha realidad: las «dos reglas» son concesiones por etiqueta, y la herencia base de datos → tabla → columna es lo que impidió que el recuento de reglas siguiera al recuento de objetos.

Caso B, Oportun: descubrimiento de PII que la dirección podía usar

El punto examinable es la forma de la respuesta: la precisión de descubrimiento mejoró porque se ajustaron los identificadores (identificadores personalizados + listas de permitidos), y la salida todavía tenía que enrutarse por EventBridge hacia una remediación construida por el cliente: Macie informó, nunca previno.

Caso C, GoDaddy: una cuenta de gobernanza central alimentando una malla de datos

Lee GoDaddy como la secuencia productor/consumidor de la Sección 5 ejecutándose a escala de malla: concesión del productor → share de RAM → aceptar → enlace de recurso → concesión separada sobre el destino enlazado, repetido miles de veces y automatizado con Service Catalog y Lambda para que la creación de enlaces nunca se convierta en un paso escrito a mano. La lección de gobernanza es que la propiedad se descentralizó mientras la semántica de permisos permaneció central: la malla publica, Lake Formation decide.

Caso D, EOS Group: enmascaramiento de PII tras una migración DMS → S3 → Redshift

Lee EOS como el verbo de enmascaramiento viviendo en un servicio distinto: los filtros de datos de Lake Formation enmascaran en el lago, el enmascaramiento dinámico de datos de Redshift enmascara en el almacén, y Macie no hace ni lo uno ni lo otro: solo encuentra la PII que ambos controles de enmascaramiento existen para proteger. El día del examen, el motor citado en el enunciado elige el mecanismo de enmascaramiento.

• 📚 ¿Sabías que…? El caso de gobernanza vecino de AWS, GoDaddy, describe una malla de datos de Lake Formation con más de 2.000 productos de datos sobre «varios petabytes de datos a través de cientos de cuentas» (AWS Big Data Blog, 2022-11-21, consultado en octubre de 2026). La cifra importa menos que la topología: una cuenta de gobernanza central publicando shares a través de AWS RAM, con consumidores que poseen enlaces de recurso: exactamente la secuencia de la Sección 5 a escala de malla.

---

Preguntas de Práctica (Practice Questions)

Veredicto comparativo: cómo se compara este tema el día del examen

• Frente a otras nubes: el DEA-C01 prueba solo servicios de AWS. Amazon Macie frente al producto DLP de un competidor, o Lake Formation frente a un catálogo externo, nunca aparece como una comparación justa: las herramientas DLP/catálogo de terceros, Azure Purview, Google Data Catalog y OpenLineage están fuera de ámbito por construcción. Responde con un servicio de AWS en ámbito (Lake Formation, Macie, CloudTrail, Config, Control Tower, KMS, IAM/RAM) o con un comportamiento documentado por AWS.
• Frente a autogestionado / on-premises: la preferencia del examen es lo gestionado, declarativo y auditable por encima de lo artesanal y manual: las concesiones por LF-Tag superan a las ACL por tabla mantenidas a mano (las «cientos de reglas → dos» de IAS), los trabajos de Macie superan a un script de escaneo casero, CloudTrail supera a un registro de auditoría propio. Una opción que describe código de permisos hecho a mano es el distractor, no el extra; la respuesta DIY además debe reimplementar lo que Lake Formation da gratis (acotamiento por Región, herencia, entrega de credenciales temporales).
• Frente a otro servicio de AWS: elige por verbo, no por proximidad: descubrir (Macie) · permitir/denegar visibilidad (Lake Formation, con IAM como Puerta 1) · cifrar (KMS) · probar que una llamada a la API ocurrió (CloudTrail) · probar el estado de configuración (AWS Config) · impedir una Región (SCP de Control Tower) · compartir datos del almacén en vivo (datashare de Redshift) · rastrear la procedencia del modelo (seguimiento de linaje de ML de SageMaker). Las respuestas erróneas casi siempre intercambian dos verbos adyacentes.
• Frente a un proceso manual y humano: la gobernanza de dos reglas de IAS y los resultados de descubrimiento de +95% / −80% de Oportun (ambos reclamados por el cliente y publicados por AWS, consultados en octubre de 2026) muestran la forma de la arquitectura objetivo, concesiones por etiqueta más descubrimiento ajustado con identificadores, pero todo porcentaje publicado es «lo logró el cliente», nunca «lo garantiza AWS». El día del examen, prefiere la opción automatizada, heredable y que produzca evidencia sobre la que depende de que un humano recuerde volver a conceder.