Certificación avanzada que valida habilidades en diseño de arquitecturas empresariales complejas y estrategias de migración en AWS.
Acceso entre cuentas, AWS Organizations, AWS Control Tower, Redes híbridas, AWS Transit Gateway, AWS Resource Access Manager
Arquitectura sin servidor, Contenedores Amazon ECS y EKS, Amazon Aurora y DynamoDB, Amazon API Gateway, AWS Step Functions, Arquitectura basada en eventos
AWS Well-Architected Framework, AWS Cost Explorer y Trusted Advisor, Políticas avanzadas de Auto Scaling, Amazon CloudWatch y X-Ray, Estrategias de caché con ElastiCache y DAX, Optimización de costos
AWS Migration Hub, AWS Application Migration Service, AWS Database Migration Service, AWS Snow Family, AWS DataSync, Estrategias de migración 6R
Prueba preguntas tipo examen del conjunto de muestra gratuito. Cada respuesta incluye una explicación completa.
Una empresa global de comercio electrónico quiere migrar completamente su servicio web desde un centro de datos local a AWS.
El sistema actual está basado en un solo servidor con contenido estático y dinámico mixto y utiliza una base de datos MySQL. Después de la migración, la arquitectura debe minimizar la latencia para usuarios globales, proporcionar protección DDoS, garantizar alta disponibilidad Multi-AZ y admitir escalabilidad automática. La base de datos debe mantener compatibilidad con MySQL mientras mejora el rendimiento de lectura, y el equipo de operaciones quiere minimizar la sobrecarga de gestión de infraestructura.
¿Qué arquitectura de migración AWS MEJOR cumple con todos estos requisitos simultáneamente?
Respuesta: B. CloudFront + ALB + Auto Scaling + Aurora MySQL
La combinación CloudFront + ALB + Auto Scaling + Aurora MySQL es la arquitectura de migración estándar que satisface los seis requisitos: minimizar la latencia global, protección DDoS, alta disponibilidad Multi-AZ, escalado automático, rendimiento de lectura compatible con MySQL mejorado y sobrecarga operacional minimizada. CloudFront proporciona protección DDoS a través de AWS Shield Standard mientras almacena en caché contenido estático en ubicaciones de borde en todo el mundo, ALB + Auto Scaling maneja la distribución Multi-AZ y el escalado automático del tráfico dinámico, y Aurora MySQL resuelve tanto la compatibilidad con MySQL como el rendimiento de lectura como un servicio totalmente administrado.
Amazon CloudFront es un servicio CDN global que entrega contenido a usuarios de todo el mundo con latencia mínima a través de más de 600 ubicaciones de borde. Amazon Aurora MySQL es totalmente compatible con MySQL mientras proporciona hasta 5x el rendimiento de MySQL estándar, y admite hasta 15 Read Replicas para distribuir la carga de lectura. La combinación de ALB y EC2 Auto Scaling Group agrega o elimina instancias automáticamente según los cambios de tráfico, eliminando la necesidad de que el equipo de operaciones gestione directamente la capacidad.
Tenga cuidado de no confundir Global Accelerator con CloudFront. Global Accelerator es adecuado para la optimización de enrutamiento de tráfico dinámico basado en TCP/UDP, mientras que CloudFront incluye almacenamiento en caché de contenido estático y dinámico basado en HTTP más protección DDoS. Cuando aparecen juntas palabras clave como servicio web mixto estático/dinámico, usuarios globales, protección DDoS y compatibilidad MySQL, la combinación CloudFront + ALB + Aurora MySQL es la respuesta correcta estándar.
Una empresa SaaS que opera en un entorno de múltiples cuentas administrado por AWS Organizations gestiona registros DNS para endpoints de microservicios internos e instancias RDS en una zona hospedada privada de Route 53 en una cuenta de servicios compartidos. Las VPCs en cuentas de carga de trabajo recién creadas también deben usar este DNS privado, pero los propietarios de cuentas de carga de trabajo no deben poder modificar directamente la zona hospedada.
En un entorno donde las cuentas de carga de trabajo se agregan continuamente, cual diseño de compartición de DNS privado MEJOR cumple con los requisitos de seguridad mientras minimiza la sobrecarga operacional?
Respuesta: B. Route 53 Resolver + RAM
Esta pregunta evalúa si puede seleccionar correctamente una arquitectura que centraliza los derechos de modificación de registros DNS en una cuenta de servicios compartidos mientras permite que las VPCs de cuentas de carga de trabajo usen DNS privado en un entorno de múltiples cuentas. Compartir una Route 53 Resolver Rule a través de AWS RAM permite que la cuenta de servicios compartidos implemente reglas de reenvío del Resolver a las VPCs de cuentas de carga de trabajo manteniendo la autoridad de registros DNS. Configurar el uso compartido basado en OU se aplica automáticamente a las cuentas recién agregadas, logrando escalabilidad y conveniencia operativa simultáneamente.
Una Route 53 Resolver Rule es una regla que reenvía consultas DNS para un dominio específico a una IP designada. Configurar un Inbound Resolver Endpoint en la cuenta de servicios compartidos permite que las VPCs de cuentas externas reenvíen consultas de dominio privado a este endpoint. Usando AWS RAM, esta Resolver Rule se puede compartir con OUs específicas o cuentas individuales dentro de Organizations, y las cuentas de carga de trabajo solo necesitan asociar la regla compartida con sus VPCs. La resolución DNS es posible sin acceso directo a la zona hospedada en sí, satisfaciendo los requisitos de seguridad.
Para las preguntas del examen AWS sobre compartición de DNS en múltiples cuentas, el criterio clave de decisión es si los derechos de modificación están aislados. Si se necesita compartición directa de zona hospedada, use la asociación de VPC entre cuentas de Route 53; si se requieren tanto el reenvío de consultas como el aislamiento de permisos, Resolver Rule + RAM es la respuesta correcta.
Una gran empresa planifica una migración a AWS con un entorno mixto de 500 VMs en VMware vSphere, 200 VMs en Hyper-V y 50 servidores físicos.
El equipo quiere recopilar automáticamente CPU, memoria, dependencias de red e inventario de software para determinar prioridades de migración. Necesitan informes de migración visualizados.
¿Qué enfoque MEJOR configura el descubrimiento e informes para un entorno heterogéneo centrado en AWS Migration Hub?
Respuesta: B. Migration Hub + Agentless Connector + Agent
AWS Application Discovery Service proporciona dos métodos para recopilar datos de configuración y rendimiento de servidores on-premises. Para entornos VMware vSphere, el Agentless Collector (appliance OVA) se despliega en vCenter para recopilar metadatos de VM sin instalar agentes. Para entornos Hyper-V y servidores físicos, el Agente se instala directamente para recopilar procesos en ejecución, conexiones de red e inventario de software. La Opción 2 combina ambos métodos para cubrir todo el entorno heterogéneo.
AWS Migration Hub agrega y visualiza centralmente los datos recopilados por Application Discovery Service. Basándose en los datos recopilados de CPU, memoria, almacenamiento y red, recomienda tipos de instancia EC2 apropiados, y la función de agrupación de aplicaciones visualiza dependencias entre servidores para establecer prioridades de migración y planes de oleadas. Todos los estados de migración se rastrean en una sola vista para proporcionar informes a los ejecutivos.
Distinga claramente los roles de las tres herramientas en el examen. Elija Application Discovery Service para recopilación de inventario on-premises, Migration Hub para seguimiento y gestión de migración, y MGN para migración real de servidor. AWS Config es exclusivamente para rastrear el estado de recursos dentro de la nube AWS y no se puede usar para el descubrimiento on-premises.
Un gran grupo financiero administra más de 200 cuentas miembro usando AWS Organizations con una SCP de denegación aplicada a nivel raíz que bloquea todo uso de servicios AWS fuera de regiones específicas.
Después de adquirir una subsidiaria extranjera, la cuenta AWS existente de la subsidiaria debe incorporarse a Organizations. La subsidiaria tiene un requisito regulatorio para mantener sus cargas de trabajo regionales existentes durante 6 meses después de la adquisición.
Para permitir a la cuenta de la subsidiaria acceso temporal a regiones adicionales mientras se mantienen las políticas de seguridad de toda la organización existente, ¿qué enfoque de diseño de SCP es MÁS apropiado?
Respuesta: B. Crear una OU dedicada para la subsidiaria y aplicar una SCP de permiso de región
Un grupo financiero controla el acceso regional de toda la organización usando una SCP de denegación en la raíz, mientras necesita otorgar a la cuenta de la subsidiaria acceso temporal a regiones adicionales durante 6 meses. Dado que las SCPs se heredan a través de la jerarquía de OU, separar la subsidiaria en una OU dedicada y agregar una SCP de permiso de región a esa OU implementa la excepción sin modificar la política raíz. Aunque la denegación siempre tiene precedencia sobre la permisión en la evaluación de SCP, la excepción se otorga separando estructuralmente el objetivo mediante la ubicación en OU.
Las SCPs son herramientas de gobernanza que establecen límites de permiso o denegación en los niveles de cuenta, OU y raíz. Aunque la SCP raíz se hereda por todas las cuentas secundarias, separar la subsidiaria en una OU dedicada permite que se apliquen SCPs adicionales solo a esa OU. Es importante destacar que el manejo de excepciones dentro de una SCP raíz usando la clave de condición aws:PrincipalAccount no está oficialmente soportado en la sintaxis de SCP, lo que hace que la separación de OU sea el único enfoque válido. Después de 6 meses, eliminar la SCP de excepción o mover la cuenta de la subsidiaria a una OU existente unifica automáticamente la política.
Cuando aparezca el manejo de excepciones de SCP en el examen, recuerde que la ÚNICA manera de otorgar excepciones sin modificar la SCP raíz es crear una OU separada. La Opción 3, que intenta eludir las SCPs con IAM Policy, siempre es incorrecta, y deshabilitar temporalmente la SCP raíz afecta a todas las 200+ cuentas y, por lo tanto, es incorrecta.
Una institución financiera gestiona toda la infraestructura AWS con CloudFormation y las plantillas se almacenan en un repositorio GitHub.
Recientemente, un desarrollador modificó una plantilla CloudFormation de pila de producción y la implementó directamente, causando un incidente donde una instancia RDS en ejecución fue reemplazada. El equipo de seguridad requiere que todos los cambios de infraestructura pasen solo por pipelines CI/CD, y se debe incluir un paso para la validación previa del impacto de los cambios antes de la implementación en producción.
¿Cuál es el diseño de pipeline CI/CD MÁS apropiado para garantizar la implementación segura de cambios de CloudFormation mientras se minimiza la sobrecarga operacional?
Respuesta: C. CodePipeline + Change Sets + paso de aprobación
Una institución financiera necesita validar el impacto de los cambios antes de la implementación en producción y hacer cumplir un pipeline CI/CD. La combinación de AWS CodePipeline + CloudFormation Change Sets + paso de aprobación manual cumple MEJOR estos requisitos. Los Change Sets muestran previamente la Action (Add/Modify/Remove) y el Replacement (True/False) de cada recurso antes de aplicar cambios a la pila real, permitiendo la detección previa de cambios destructivos como la sustitución de instancias RDS y bloqueándolos en el paso de aprobación manual.
AWS CodePipeline es un servicio CI/CD totalmente gestionado que automatiza las etapas: detección de cambios en la fuente de GitHub → creación de Change Sets → revisión y aprobación → ExecuteChangeSet. Dado que el pipeline controla todas las rutas de implementación, previene estructuralmente la implementación directa por parte de los desarrolladores. Cuando el campo Replacement en CloudFormation Change Sets muestra True, significa que el recurso existente será eliminado y recreado, permitiendo al aprobador rechazar la implementación o elegir una alternativa.
En el examen, recuerde la combinación de Change Sets y un paso de aprobación manual como el núcleo de las preguntas de implementación segura de CloudFormation. StackSets es para implementar la misma plantilla en múltiples cuentas y regiones, y no está relacionado con la validación del impacto de cambios para una sola pila. CDK Diff + implementación manual no es aplicación a través de un pipeline CI/CD, dejando el riesgo de que los desarrolladores aún puedan implementar directamente.
El examen AWS Certified Solutions Architect - Professional (SAP-C02) consta de 75 preguntas y tiene un límite de 180 minutos.
La puntuación de aprobación del examen SAP-C02 es de 750 sobre 1000.
El conjunto de muestra de SAP-C02 (20 preguntas con explicaciones completas) es gratuito. El banco completo de más de 340 preguntas está disponible con una suscripción a CloudMasterIT.
La certificación SAP-C02 es válida durante 3 años después de aprobar. Después se requiere recertificación.