Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 1

Primera parte de los apuntes del examen. La idea es que identifiques los principales temas para el examen de certificación y conocer algunos tips de estudio para alcanzar con éxito tu meta 🎓

Características generales

La complejidad es de nivel medio. A mi criterio lo más complejo son las diferentes formas de soporte vía SSM.

Consta de 5 dominios y toda la información detallada la podemos encontrar aquí.

Solo se puede rendir en inglés, con lo cual es prioritario estudiar con apuntes, entrenamiento de preguntas y laboratorios en este idioma. Se aprueba con 720 puntos.

Es una certificación que te invita a conocer en profundidad las arquitecturas mas tradicionales de AWS , la resolución de problemas en producción y el mantenimiento evolutivo al momento de actualizar infraestructura para la continuidad del negocio.

⭐ Se superponen varios temas con Solutions Architect Associate y Developer Associate. Si ya rendiste alguna, te va a resultar familiar un % del contenido.

Método de estudio

Estudiar para una certificación no tiene fórmulas mágicas, se necesita apartar tiempo de nuestro dia y constancia. Tener en claro que nos permite profundizar en conceptos o prácticas que tal vez no vemos en el trabajo diario...esa será nuestras motivación.

1. Tu punto de partida debe ser la guia de examen siempre.
2. Conviene hacer la preparación de examen de SkillBuilder, te da un paneo general de temas y asi podes identificar las brechas de conocimientos en las que debes profundizar.
3. Mi forma favorita de estudiar es hacer una especie de RAG con NotebookLM con la documentación oficial de AWS pertinente (aws permite bajar los pdf).
4. La novedad es que hay mcp de AWS disponibles referidos a la documentación. Por ejemplo, utilizando los temas de la guia de examen como contexto, se puede generar apuntes. Utilice este mcp , pero tambien hay uno que no he probado que es mucho más amplio y contiene temas de arquitectura aquí

⭐ Resumen de los Dominios de examen generado por kiro con el mcp de la documentación de AWS.

⭐ Utilicé Tutorials Dojo como banco de preguntas para practicar, pero mi percepción es que las preguntas en el examen eran más difíciles.

Arquitecturas importantes

Te invito a pensar en sus variantes para lograr alta disponibilidad, escalabilidad y resiliencia. Los temas de networking son importantes en el examen: configuración de VPC, subnet, tablas de ruteo, Security Groups entre otros, especialmente troubleshooting de conectividad.

High Available (Route53)

High Available and Scalable Web App (Cloudfront - ALB)

Worker Fleet - SQS

VPC Peering

Transit Gateway

Cloudfront - OAC

Config

Temas que son claves conocer para el examen

Las preguntas de examen se centran en la resolución de problemas con menos carga operativa y la elección de arquitecturas más lógica.

CloudWatch

Familiarizarse con las features de la consola de CloudWatch porque vas a enfrentarte a varias preguntas sobre la administración de logs.

• Cómo visualizó los logs comunes? **CloudWatch > Logs > Log Management. Aquí se encuentran todos los "Logs Groups" como aws/lambda/..., aws/apigateway/...,ecs/..., ec2..
• Cómo creo un Log Group? Desde la CLI de AWS. Cómo inserto Log en CloudWatch? Desde la Api con Create
• CloudWatch metrics, tener en claro las diferentes tipos y circunstancias a utilizar. Cada métrica tiene un nombre, namespace y dimensiones (opcional).
  • Basic Monitoring (5 min, default).
  • Detailed Monitoring (1 min, se habilita manualmente)
  • High Resolution para métricas custom (hasta 1 segundo).
• Metric Filters ➡ Definís un patrón de búsqueda sobre un Log Group y CloudWatch genera una métrica custom a partir de las coincidencias.
  • El caso de uso típico a resolver: detectar cantidad de errores 500 en logs de una aplicación. Metric Filter sobre el Log Group (métrica custom) → alarma de CloudWatch sobre esa métrica y acción de remediación automática.
• CloudWatch Agent ➡ es uno de las features más importantes que nos va a permitir enviar Logs a CloudWatch desde las instancias de EC2, server onprem, EKS cluster (recopilar métricas y registros a nivel de nodo de los contenedores).
  • Comprender cómo se configura y se modifica el archivo de configuración del agente (sin reiniciar las instancias de EC2): amazon-cloudwatch-agent-ctl command with the fetch-config
• CloudWatch Logs Insights: sintaxis y comandos para el análisis de logs ➡ fields , display , filter , stats , sort , limit ...

Escalabilidad y Elasticidad

• Administración de Fleet de EC2: Estrategias para continuar procesamiento de trabajos minimizando las interrupciones de form costo-efectiva ➡ capacity-optimized para minimizar interrupciones o price-capacity-optimized para balance entre costo y disponibilidad. (Combinando instancias Spot y On-Demand con el parámetro OnDemandBaseCapacity se especifica cuántas instancias base On-Demand y el resto se cubre con Spot).
• EC2 Auto Scaling Group: puede aparecer pregunta puntual sobre administrar ASG, pero por lo general no aparece como concepto aislado sino asociado a un balanceador de carga (ALB/NLB) y en arquitecturas multi-región con Route 53.
  • Capacidad mínima, máxima y deseada.
  • Definición de Launch template, cómo aplicar una nueva configuración a todas las instancias del ASG sin downtime? ➡ Cuando se actualiza un Launch Template, las instancias existentes no se reemplazan automáticamente, siguen ejecutando la versión anterior. Las nuevas instancias que escalen usarán la versión nueva. Para forzar el reemplazo se usa Instance Refresh.
  • Distribución en AZ.
  • Health Checks de EC2 o si health checks desde un ELB determina que las instancias que no están en buen estado se reemplazan automáticamente. Profundizar en este punto
  • Es clave entender las siguientes políticas de escalamiento para responder sobre mejora de performance.

Tipo de Política	Cómo Funciona	Caso de Uso
Target Tracking	Mantiene una métrica en un valor objetivo (ej: CPU al 50%). AWS gestiona las alarmas de CloudWatch automáticamente.	Aplicaciones web generales donde querés simplicidad sin configuración compleja.
Step Scaling	Ajusta la capacidad en pasos según cuánto se desvía una métrica del umbral. Permite diferentes tamaños de paso según la magnitud.	Workloads con picos abruptos donde necesitás agregar más instancias cuanto mayor es el desvío.
Simple Scaling	Agrega o quita una cantidad fija de instancias cuando se dispara una alarma. Incluye período de cooldown antes de la siguiente acción.	Legacy, no recomendada. Target Tracking la reemplaza en casi todos los casos.
Scheduled Scaling	Escala la capacidad en un horario específico usando expresiones cron.	Cargas predecibles: horario comercial, cierre de mes, campañas programadas.
Predictive Scaling	Usa ML para predecir la carga futura y ajusta la capacidad de forma proactiva.	E-commerce con patrones cíclicos (ej: picos semanales o estacionales recurrentes).

• LifeCycle Hooks: En Auto Scaling Group para analizar errores de las instancias antes de que se finalicen para ser reemplazadas se puede pausar la finalización de la instancia. También, este mecanismo, al inicio permite acciones como instalación de software. La instancia permanece en estado Pendiente
• Conocer el término Warmup, define un tiempo de calentamiento de la instancia. Es el período posterior al lanzamiento de una nueva instancia antes de que sus métricas contribuyan a la métrica de escalado. Evita el escalado por falsas métricas hasta que la instancia se estabilice.
• Application AutoScaling (no confundir con ASG):
  • ECS, cantidad de task.
  • Lambda. Entender la diferencia entre Provisioned Concurrency y Reserved Concurrency. La primera es la que permite "autoescalar" ➡ muy probable que te planteen una situación con Lambda para resolver temas de concurrencia.
  • Aurora réplicas. Permite liberar la instancia del cluster, teniendo réplicas de lectura (no de escrituras).
  • DynamoDB, puede crear una política de AutoScaling. Luego DynamoDB pública métricas de capacidad consumida CloudWatch ➡ La alarma de CloudWatch invoca a AutoScaling de aplicaciones para evaluar la política de escalado, emite una solicitud UpdateTable para ajustar el rendimiento aprovisionado de la tabla.

ELB - High availability

Con el siguiente cuadro podés responder varios casos de uso:

Load Balancer	Capa	Protocolos	Características Clave
Application Load Balancer (ALB)	Layer 7 (HTTP/HTTPS)	HTTP, HTTPS, gRPC, WebSocket	Enrutamiento basado en contenido (path, host, headers, query strings), targets Lambda, integración con WAF, sticky sessions.
Network Load Balancer (NLB)	Layer 4 (TCP/UDP)	TCP, UDP, TLS	Ultra-baja latencia, IP estática por AZ, soporte Elastic IP, preserva la IP de origen, maneja millones de requests/segundo.
Gateway Load Balancer (GWLB)	Layer 3 (IP)	IP	Despliega, escala y gestiona appliances virtuales de terceros (firewalls, IDS/IPS). Usa protocolo GENEVE.
Classic Load Balancer (CLB)	Layer 4 y 7	HTTP, HTTPS, TCP, SSL	Legacy; no recomendado para nuevos despliegues.

• Dónde encontrar información detallada como la dirección IP del cliente, latencias, rutas de solicitud y respuestas del servidor? ➡ La respuesta es habilitar los ELB Access Logs y almacenarlos en un bucket de S3.
• Problemas de conectividad. Una web inalcanzable con grupos de seguridad correctos ➡ La solución es permitir puertos efímeros (1024-65535) en la Network ACL (NACL), porque ELB utiliza este rango para comunicarse con los clientes.
• Sticky Sessions: Caso de uso donde una sola instancia EC2 tiene un uso de CPU del 95% mientras las otras están al 10% ➡ ajustar la expiración de las cookies de la aplicación para rebalancear la carga.
• Conocer Cross-Zone Load Balancing para asegurar una distribución uniforme del tráfico en todas las zonas de disponibilidad habilitadas.
• Integración de ALB con WAF pero no así con NLB.

Placement Group

Cluster: Agrupa las instancias muy cerca unas de otras en una única zona de disponibilidad. Proporciona una red de baja latencia y alto ancho de banda (hasta 100 Gbps con EFA). Casos de uso ➡ HPC, Machine Learning,

Partition: Divide las instancias en particiones lógicas, cada una en racks separados con alimentación y red independientes. Hasta 7 particiones por zona de disponibilidad. Caso de uso ➡ base de datos Distribuidas: Cassandra,HDFS, Kafka

Spread: Cada instancia se ubica en un hardware distinto (racks separados). Máximo 7 instancias por zona de disponibilidad por grupo. Caso de Uso ➡ grupos de instancias que deben aislarse entre sí en hardware separado.

Estrategias de Disaster Recovery

Conceptos principales RTO (Recovery Time Objective), RPO (Recovery Point Objective) ➡ mientras mas pequeños mas costosos. Este enlace tiene información detallada que vale la pena revisar de las siguientes estrategias:

Estrategia	RTO	RPO	Costo	Caso de Uso
Backup and Restore	Horas	Horas	$	Dev/test, no-crítico
Pilot Light	Varios minutos	Minutos	$$	Apps internas, criticidad moderada
Warm Standby	Minutos	Segundos–minutos	$$$	Apps de negocio críticas
Multi-Site Active/Active	Segundos	Segundos	$$$$	Crítico, zero-downtime

Clases de S3 - Versiones - Eventos

• Hacer un pequeño cuadro comparativo de versiones de S3 y que casos de uso se utiliza para cada uno. Ejemplo ➡ cuando los patrones de acceso son impredecibles o cambiantes y no querés gestionar manualmente las políticas de ciclo de vida: S3 Intelligent-Tiering
• S3 Object Lock ➡ cuando se usa Governance mode o Compliance mode.
• Activación de versionado. Relación con CRR (Cross Region Replication) y SRR (replicación en misma región pero diferentes cuentas).
  • Resolución de problemas de latencia o errores cuando el S3 es origen de CloudFront: Si hay millones de versiones y las operaciones de listado o ciclo de vida se vuelven pesadas ➡ Configurar S3 Lifecycle Policies para expirar versiones antiguas automáticamente, usando NoncurrentVersionExpiration para eliminar versiones no actuales después de cierta cantidad de días.
• Event notifications para creación, eliminación, update de objetos. Integración con Lambda, SNS y Eventbridge. EventBridge permite filtrar eventos por prefijo, sufijo, tamaño, etc. y enrutarlos a más de 20 destinos distintos.
• Conocer las políticas de bucket para responder preguntas sobre que habilita o deniega una policy. Su alcance. Entender que un Deny explícito siempre gana, incluso si hay un Allow en otra política.

ElastiCache

Conocer las llamadas básicas de la API es básico ➡ saber como crear un cluster CreateCacheCluster, parámetros importantes como CacheNodeType

• ElastiCache - Memcached: caso de uso que recibe alertas relacionadas con un alto uso de CPU en un clúster de Amazon ElastiCache Memcached, cómo solucionarlo? ➡ Agregar nodos adicionales proporcionará mayor capacidad al clúster o bien según la versión de Memcached se puede escalar verticalmente cambiando el tipo de nodo sin necesidad de crear un nuevo cluster. No tiene replicación, ni persistencia.
• ElastiCache - Redis: El concepto más importante de esta opción es permitir Alta Disponibilidad a través de sus réplicas: Multi-AZ con failover automático. División en sharding. Compatible con PUB/SUB. Adecuado para conservar sesiones. El soporte más común a resolver por performance es cambiar el tipo de nodo.

SSM (Simple Service Manager)

Si no trabajas todos los días con este servicio, es necesario que no solo estudies teoría en cuanto a sus features, sino que también hagas laboratorios.

Las preguntas que aparecen en el examen son muy variadas en cuanto a la administración de EC2, aplicación de parches, auto aprobaciones de releases y algunas que involucran webhooks con github.

Recomiendo mirar la sintaxis de los documentos en JSON o Yaml que definen acciones y flujos de trabajo automatizados ➡ hay preguntas sencillas sobre este punto en el examen.

Enumero algunas situaciones o casos de uso:

• Un concepto sencillo útil: todas las ejecuciones se puede trackear su estatus y log de salidas desde la consola de System Manager.
• Se quiere automatizar la creación de Amazon Machine Images (AMIs) personalizadas. Se detecta errores timeout sobre el pipeline de EC2 Image Builder ➡ El agente de AWS Systems Manager (agente SSM) en la instancia de compilación no se está ejecutando o no está accesible.
• ¿Cómo dividimos los parches entre servidores de diferentes cuentas/entornos y SO? ➡ La solución combina Patch Baselines (definen qué parches aplicar, con aprobaciones automáticas y listas de rechazo, por SO) + Patch Groups (agrupan nodos mediante tags y los asocian a una Baseline específica).

Runbook: Tipo específico de documento de Systems Manager (SSM) que define las acciones exactas que realiza el servicio Automation. Define yaml o json para orquestar un workflow de ejecución.

• Por lo general, se usa para la remediación asociado con AWS Config.
• Usando AWS Organizations se necesita automatizar el proceso de stopping de instancias EC2 no productivas fuera del horario de negocio de todos las cuentas miembro ➡ Crear roles de IAM en cada cuenta con los permisos adecuados, utilizar Systems Manager Automation con una cuenta de administrador delegado para ejecutar un runbook que dirija los recursos de toda la organización según los tags.
• Patch Policies: se utiliza para Organizations. Tener en claro que centraliza el control para definir patching schedules y baselines para múltiples cuentas y regiones
• Revisar los documentos de ejecuciones más importantes en SSM.
• Integraciones por eventos externos, tener claro cómo trabaja en los diferentes casos webhooks (con avisos de software de terceros). Que flujos podemos tener:
  • Webhook → API GW → Lambda → SSM
  • GitHub Actions → SSM (puedes filtrar exactamente por eventos RELEASED o PRERELEASED).
  • Amazon EventBridge Partner Events → GitHub como fuente nativa de eventos → SSM Automation o Lambda como destino.
  • EventBridge Scheduler → Lambda consulta GitHub API → escribe versión en SSM Parameter Store (como fuente de verdad para actualizaciones)
• AWS RunRemoteScript: Documento SSM que permite ejecutar scripts alojados en S3 o GitHub directamente en los nodos, sin necesidad de copiarlos previamente.

Servicios y estrategias de Deployment

• Casos de uso de AWS Code Pipeline, y los otros servicios que involucra ➡ Code Commit o GitHUb, Code Build, Code Deploy o CloudFormation. Entender donde se integran los test y tener en cuenta que se puede agregar una aprobación vía sns antes de realizar deploy.
• CodePipeline puede implementar CloudFormation StackSets, lo que permite implementaciones en múltiples cuentas y regiones como parte de una canalización de CI/CD.
• Estrategias de deployment:
  • In-place (All-at-once): Implementa en todas las instancias simultáneamente. Downtime Posible. Es Lento (redeploy versión antigua). Se usa en entornos de desarrollo, cuando el downtime es aceptable
  • Rolling: Reemplazar instancias en lotes. Downtime Mínimo. Se usa cuando querés ahorrar costos sin aprovisionar nueva infraestructura.
  • Rolling with additional batch: Agrega nuevas instancias antes de eliminar las antiguas. Downtime mejor que el anterior. Se usa cuando necesitas mantener capacidad completa durante el deploy
  • Immutable: Inicia instancias completamente nuevas; intercambia cuando estén en buen estado. Se usa en producción donde el rollback rápido es crítico.
  • Blue/Green: Ejecuta dos entornos idénticos; cambia el tráfico. Downtime mínimo. Se usa cuando necesitás rollback instantáneo y podés asumir el costo de doble infraestructura.
  • Canary: Desvía primero un pequeño % del tráfico; lo va ampliando si todo está OK. Es rápido. Se usa para validar un release con un subconjunto de usuarios antes de rollout completo.

Cloudformation

Es un servicio fundamental en el examen. Conocer las secciones principales de la plantilla (JSON o YAmL) : Metadata, Parameters, Mappings (caso de uso de parametrización de Amazon Machine Images (AMIs) ), Conditions, Transform (SAM), Resources.

• Una buena práctica para familiarizarse con la sintaxis de los templates es construir arquitecturas clásicas que utilicen EC2, ASG, ALB, RDS con Secret Manager, entre otras.
• Comandos CLI importantes:
  • aws cloudformation create-stack ➡ crea un stack nuevo
  • aws cloudformation deploy ➡ crea o actualiza un stack usando un template empaquetado (más usado en CI/CD)
  • aws cloudformation detect-drift ➡ inicia la detección de drift en un stack
  • aws cloudformation describe-stack-drift-detection-status ➡ consulta el resultado de la detección
  • aws cloudformation cancel-update-stack ➡ cancela una actualización en curso
• StackSet ➡ caso de uso importante de cuentas asociadas en Organizations. Gestiona de manera centralizada para implementar cambios en las stack en varias cuentas. Se puede usar StackSets para crear, actualizar o eliminar stacks en varias cuentas y regiones de AWS con una sola operación.
• Intrinsic functions: comandos que se utilizan dentro de las plantillas para asignar valores a propiedades que no están disponibles hasta el momento de la implementación (en tiempo de ejecución) ➡ revisar implementaciones de las mas importantes: Ref , Fn::GetAtt, Fn::ImportValue, Fn::FindInMap, Fn::ForEach, Fn::Transform ...
• NestedStack: AWS::CloudFormation::Stack ➡ mecanismo para crear infraestructura modular, reutilizable y gestionable mediante la integración de una pila dentro de otra. En lugar de crear una plantilla única y masiva que resulta difícil de mantener, se puede dividir la arquitectura en componentes lógicos (por ejemplo, VPC, base de datos, capa de aplicación) y referenciarlos como pilas separadas dentro de una plantilla "raíz" o "padre".
• Mecanismos de protección en CloudFormation:
  • Stack Policy: documento JSON que restringe qué recursos pueden ser actualizados. Ideal para proteger RDS de producción de cambios accidentales.
  • Termination Protection: protección a nivel stack contra eliminación accidental. Se hereda a los nested stacks.
  • DeletionPolicy: Retain conserva el recurso, Snapshot genera snapshot antes de eliminar (soportado en RDS, EBS). La situación típica que se plantea, como conservar una RDS si se elimina el stack de cloudformation?
  • UpdateReplacePolicy: igual que DeletionPolicy pero aplica cuando un update requiere reemplazar el recurso físico.
  • Drift Detection: detecta recursos cuya configuración real difiere del template, útil para identificar cambios manuales que bypasearon el pipeline.
• Profundizar en los Script Auxiliares más importantes, mecanismos para sincronizar la creación o actualización de recursos, para que el stack espere hasta que la configuración esté lista antes de continuar.
  • cfn-init → lee y ejecuta la sección AWS::CloudFormation::Init del template (instala paquetes, archivos, servicios). Se ejecuta durante el User Data.
  • cfn-signal ➡ Generalmente se implementa al final de un script de User Data. Un patrón común es ejecutarlo después de cfn-init
  • Tener en cuenta los atributos que requieren señales como CreationPolicy (puede estar asociados con AWS::EC2::Instance o AWS::AutoScaling::AutoScalingGroup ) y los tipos de UpdatePolicy (con WaitOnResourceSignals).
• CloudFormation Traffic Shifting ➡ se implementa definiendo DeploymentPreference en el template. CodeDeploy ejecuta el shifting según la estrategia elegida (Canary, Linear, AllAtOnce).

Storage

Evaluar y seleccionar que tipo de Storage es adecuado a un caso de uso. Si estudiaste para la certificación de SAA son preguntas similares.

• Storage en entornos híbridos ➡ Storage Gateway y todas sus variantes
  • S3 File Gateway: Acceso NFS/SMB a objetos en S3. Los archivos se almacenan como objetos nativos. Caso de uso: migración de archivos on-premise a S3.
  • Volume Gateway:
  • Cached mode: datos principales en S3, caché local de los más accedidos.
  • Stored mode: datos principales on-premise, backup asíncrono a S3 como EBS snapshots.
  • Tape Gateway: Reemplaza cintas físicas. Importante es que se expande automáticamente, esta última característica puede ser un caso de uso que aparezca en el examen.
  • FSx File Gateway: Caché local de FSx for Windows File Server para acceso de baja latencia desde on-premise.
• FSx for Windows FileServer y su otras variantes, cuando usarlo?
  • Es MultiAZ, es una feature importante.
  • Shadow Copies: los usuarios finales puedan ver y restaurar por sí mismos versiones anteriores de archivos o carpetas individuales sin depender de otro mecanismo.
  • Usado con Windows SMB, Active Directory.
• FSx for Lustre ➡ HPC, ML, high throughput
• EFS (Elastic File System) comprender el caso de uso que puede compartir storage entre varias EC2, Linux NFS.
  • Multi-AZ
  • Performance modes: general Purpose y MaxIO
  • Throughput Modes: Elastic (recomendado), Provisioned, Bursting.
  • Conocer qué EFS tiene Storage Class y Lifecycle Policies ➡ aunque suele no aparecer en el examen.
• EBS ➡ siempre en el contexto de EC2 y la elección del disco para optimizar las cargas de trabajo: gp3 sobre gp2 sin incrementar los costos, gp3 permite configurar IOPS y throughput independientemente del tamaño del volumen. Para transacciones, persistencia y durabilidad es io2
  • Amazon Data Lifecycle Manager (DLM): Automatiza la creación, retención y eliminación de instantáneas de EBS y AMI respaldadas por EBS mediante políticas de ciclo de vida.
  • EBS Snapshot: Una copia de seguridad puntual de un volumen EBS almacenado en S3 (gestionado por AWS). Los snapshot son incrementales.

RDS y Aurora

Los accesos se deben guardar en Secrets Manager y luego las aplicaciones acceden a eso. Característica importante Cross-Region backup replication. Tanto RDS como Aurora tienen PITR (Point-in-Time Restore).

• RDS Multi-AZ ➡ standby síncrono en otra AZ, failover automático pero más lento que Aurora.
• Se puede asociar con el servicio RDS Proxy para el manejo de conexiones.
• Aurora ➡ Almacenamiento distribuido que se replica automáticamente en 3 AZs, hasta 15 réplicas de lectura, failover automático en segundos.
• Aurora Serverless v2 ➡ la característica importante es que escala a "cero" y no genera costo.

DynamoDB

Las preguntas se centran en resolver problemas de performance; cómo volver a un recovery point. Ejemplo: La tabla experimenta picos de tráfico incrementales durante el horario laboral, con patrones predecibles, cuando se producen millones de lecturas y escrituras. Hay que configurar una solución para aumentar la capacidad de procesamiento ➡ Habilitar el escalado automático en la tabla de DynamoDB. Configurar una política de escalado automático para ajustar el tamaño en función de las unidades de capacidad de lectura y escritura.

• Point-in-Time Recovery (PITR) ➡ backup continuo, permite restaurar a cualquier segundo de los últimos 35 días.
• Para esto debemos conocer los tipos de Lectura Eventually Consistent Read (por defecto) y Strongly Consistent Read
• Los diferentes modos de capacidad On-Demand y Provisioned (profundizar en estos dos conceptos).
• DynamoDB Global Tables ➡ replicación multirregional y multiactiva. Cada región puede aceptar lecturas y escrituras, y los cambios se replican de forma asíncrona. Esto permite la escalabilidad global y la recuperación ante desastres.

Encriptación en reposo, tránsito y uso de KMS

• Encriptación con S3 de KMS: SSE-S3 (clave gestionada por AWS), SSE-KMS (usás una KMS key propia, permite auditoría via CloudTrail y control de acceso granular) y SSE-C (el cliente provee la clave, AWS no la almacena). Si la pregunta menciona auditoría de uso de claves o control granular ➡ SSE-KMS.
• Clave simetrica y asimetrica son básicos. Aunque en el examen no hay preguntas profundas sobre este punto.
• Key Policies: Cada clave KMS tiene una política de claves. Una política basada en recursos que controla quién puede usar y administrar la clave. A diferencia de las políticas de IAM, la política de claves es el principal mecanismo de control de acceso para las claves KMS.
• Rotación de Key, hay 3 variantes:
  • automática, para customer managed keys puede habilitar la rotación automática
  • manual u On-demand por medio de trigger.
• Importación de material de clave de un cliente en KMS, pero no rota automáticamente.
• Replicación AWS KMS Multi-Region Keys: Una clave KMS que existe en una región diferente, pero comparte el mismo ID de clave y material de clave que su clave principal.

AWS Certificate Manager (ACM)

Las preguntas son sencillas, si se habla que servicio proporciona certificados SSL/TLS la respuesta es ACM.

• Revisar los casos de uso de como integrar ACM con ELB, CloudFront, ApiGateway, Elastic Beanstalk, Cognito.
• Tipos de certificados ➡ públicos, privados e importación de terceros. Identificar los casos de uso para poder resolver situaciones.
• Mecanismo de renovación e importación de certificados de terceros.

Seguridad IAM

• Pensar que todo servicio para ejecutar algo debe tener un rol de IAM asociado. En ciertas ocasiones para permitir que usuarios utilicen servicios o listen ciertas features de manera temporal podemos agregar inline policies y luego eliminarlas.
• Casos de uso de iam:PassRole. Entender por qué es una capa de seguridad importante para proteger el entorno de AWS de actividades no deseadas y de la escalada de privilegios.
• Caso de uso de credenciales temporalesiam:AssumeRole. Ejemplo ➡ la entidad en la Cuenta A utiliza para ejecutar servicios en la Cuenta B como si fuera un usuario local en esa cuenta.
• Federación de Identidades: Permite a los usuarios autenticados por un proveedor de identidad externo (IdP) acceder a AWS sin crear usuarios de IAM individuales. Conocer los casos de uso:
  • SAML 2.0: se integra con Microsoft Active Directory Federation Services (ADFS) u Okta. Los usuarios se autentican con sus credenciales corporativas y reciben credenciales temporales de AWS.

OpenID Connect (OIDC):

• para aplicaciones web y móviles. Admite proveedores de identidad como Google, Facebook o cualquier proveedor compatible con OIDC. Solución de error "Not authorized to perform sts:AssumeRoleWithWebIdentity" ➡ agregar el ARN del proveedor de identidad en el elemento principal de la política de confianza (trust policy).

AWS Organizations

• OU (Organizational Units): las cuentas se agrupan en OUs y los SCPs se aplican a nivel OU o cuenta individual, heredando hacia abajo en la jerarquía.
• Delegated Administrator: permite que una cuenta miembro (no la cuenta de administración) gestione servicios específicos como Security Hub, GuardDuty o Config para toda la organización.
• Relaciona el concepto de administrar muchas cuentas con Service control policies (SCPs). Recordar que afectan únicamente a los usuarios y roles de IAM gestionados por las cuentas que forman parte de la organización. SCPs no afectan directamente a las políticas basadas en recursos.
• Políticas de tagging. Se puede asegurar que los usuarios no puedan crear recursos sin una etiqueta específica.
• Integración con CloudFormation StackSet. Definir un StackSet que implementa una plantilla base (almacenada en S3) en toda una Unidad Organizativa (OU) en varias regiones utilizando Service-Managed permission model.
• Consolidated Billing: todas las cuentas miembro consolidan el pago en la cuenta de administración, permite aprovechar descuentos por volumen y Reserved Instances compartidas entre cuentas.

AWS Artifact

Su caso de uso es acceder a informes de auditoría. Se puede descargar bajo demanda certificaciones de cumplimiento normativo (como SOC 1/2/3, ISO/IEC, y PCI DSS).

---

Este apunte continua en ➡ Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 2