AWS CloudOps Engineer - Associate (SOA-C03) — Preguntas de práctica y simulacro de examen

Razona hacia atrás a partir de lo que el escenario ya descarta. El acceso general a internet demuestra que el enrutamiento funciona. Las network access control lists están abiertas, así que la subred no está filtrando. La política del bucket de S3 permite el acceso desde la VPC, y ahí está la pista, porque una política escrita así solo se cumple cuando la solicitud llega realmente por la ruta del endpoint privado. El tráfico que sale por un NAT gateway llega al endpoint público de S3 y no lleva contexto de endpoint, así que la política lo deniega aunque los paquetes lleguen.

Eso convierte al VPC endpoint para S3 en lo que hay que revisar. ¿Existe un gateway endpoint para S3 en esta VPC, y su asociación de tabla de rutas incluye la subred privada? Crear el endpoint es solo la mitad del trabajo; después lo agregas como destino en la tabla de rutas para el tráfico dirigido a S3, y una subred cuya tabla de rutas nunca se asoció sigue usando la ruta de internet.

Las otras tres no encajan con los síntomas. El ancho de banda del NAT gateway causaría lentitud, no una denegación tajante. El versionado del bucket es una configuración de protección de datos que no incide en el acceso. El permiso del rol de la instancia es una trampa que suena plausible, pero el enunciado te dice que la política del bucket es el control en juego.

Consejo de examen: cuando la conectividad funciona en general y falla un solo servicio, busca en la política del recurso una condición que restrinja la ruta, no solo el principal.

Sobrevivir a la pérdida de una Availability Zone requiere dos cosas: una copia de los datos en otro lugar y algo que promueva esa copia automáticamente. Habilitar el cluster mode con réplicas repartidas entre varias Availability Zones aporta la copia, y el auto-failover Multi-AZ aporta la promoción: detecta que el primario está inalcanzable y elige una réplica en una zona que sigue en pie, sin que un operador intervenga. Por eso esta configuración mejora la tolerancia a fallas justo en la falla que describe el escenario.

Fíjate en lo cuidadosa que es la redacción sobre la pérdida de datos. La replicación hacia las réplicas es asíncrona, así que las escrituras que el primario confirmó un instante antes de caer quizá nunca llegaron a una réplica. Lo defendible es afirmar pérdida de datos mínima, no cero, y una respuesta que promete cero pérdida con replicación asíncrona suele ser la equivocada.

Los distractores fallan en disponibilidad. Los snapshots diarios son un respaldo, útil para restaurar después de una corrupción, pero se miden en horas de pérdida y una restauración manual. Los nodos independientes en distintas zonas no comparten datos, así que perder uno significa perder las sesiones que vivían ahí. La persistencia append-only en un solo nodo sobrevive al reinicio del proceso en ese nodo, pero el nodo sigue estando en una sola zona y no hay nada hacia donde hacer failover.

Consejo de examen: separa durabilidad de disponibilidad. Los snapshots y la persistencia dan durabilidad; las réplicas más la promoción automática dan disponibilidad.

Aplicar una etiqueta a una instancia es una llamada a la API, y esa llamada es el gancho del que cuelga toda la automatización. El etiquetado pasa por la acción CreateTags de Amazon EC2, AWS CloudTrail registra esa llamada como evento de administración, CloudTrail entrega los eventos que registra a Amazon EventBridge, y una regla de EventBridge cuyo patrón de eventos coincide con esa llamada a la API y esa clave de etiqueta invoca a AWS Lambda como destino. La función de Lambda crea entonces el bucket de S3 mediante el SDK. Nada hace polling, nada corre por temporizador y la reacción ocurre porque ocurrió la llamada a la API, que es justo lo que significa basado en eventos.

Las otras tres combinaciones se rompen en su primer paso. Las métricas de Amazon CloudWatch son series temporales numéricas y ninguna métrica lleva una clave de etiqueta y su valor, así que nada en esa cadena puede detectar el cambio, y poner a Amazon SNS delante de AWS Lambda solo reenvía una notificación que nunca se generó. Una regla programada de Amazon EventBridge que consulta etiquetas por polling es lo contrario de basado en eventos: despierta por temporizador, añade latencia de hasta el intervalo de polling y se ejecuta constantemente aunque no haya cambiado nada, así que AWS Step Functions detrás de ella hereda ese retraso. La opción de AWS Config es la más cercana a ser plausible, porque AWS Config sí evalúa cambios de configuración de recursos, pero pasar por AWS Systems Manager y AWS CloudFormation para crear un solo bucket es maquinaria mucho más pesada de la que el escenario necesita, y deja fuera la coincidencia de patrones de EventBridge, que es la que hace el filtrado real.

Consejo de examen: ante un requisito con la forma cuando pase esto, haz aquello, la respuesta estándar de AWS es CloudTrail registra la llamada a la API, EventBridge hace coincidir el patrón de eventos y Lambda ejecuta la acción. Reconocer ese trío responde de un vistazo a la mayoría de las preguntas sobre automatización basada en eventos.

Lee las dos restricciones juntas: cifrado en tránsito y certificados administrados por AWS. AWS Certificate Manager, o ACM, aprovisiona certificados públicos, los valida y los renueva automáticamente, y ACM se integra con Elastic Load Balancing, así que puedes desplegar el certificado directamente en el load balancer. Adjuntas el certificado aprovisionado al listener HTTPS del ALB y la plataforma se encarga del resto del ciclo de vida, sin material de claves que copiar en las instancias y sin fecha de renovación que recordar.

Cada distractor rompe una de las restricciones. Los certificados autofirmados generados en cada instancia con OpenSSL no están administrados por AWS en absoluto, y los clientes los rechazan a menos que distribuyas la confianza a mano. AWS KMS crea y controla claves criptográficas; no es una autoridad certificadora y no genera certificados TLS. Cargar certificados de servidor de IAM todavía funciona para configuraciones antiguas, pero esos certificados se obtuvieron en otro lado y la renovación corre por tu cuenta, que es justamente la carga de administración que la pregunta te dice que evites.

Consejo para el examen: certificados administrados por AWS más un load balancer es una pareja fija. Si después la pregunta agrega cifrado entre el load balancer y las instancias que están detrás, trata la conexión del back-end como una decisión aparte del certificado del listener.