Una organización utiliza AWS Organizations con ocho cuentas miembro y anticipa un máximo de 20 cuentas. La empresa ejecuta todas las cargas de trabajo en AWS y tiene una nueva política de seguridad que requiere: • Ninguna cuenta ejecuta cargas de trabajo en una VPC dentro de esa cuenta. • Todas las cargas de trabajo deben lanzarse en subredes de una VPC administrada centralmente y accesible por todas las cuentas. • Ninguna cuenta puede modificar los recursos de aplicación de otra cuenta dentro de la VPC compartida. • La VPC administrada centralmente debe residir en una cuenta existente llamada Account-A en la organización. Una plantilla de CloudFormation en Account-A crea la VPC y varias subredes y exporta los ID de subred como salidas de pila. ¿Qué solución completa la configuración para satisfacer estos requisitos?

La opción correcta es utilizar AWS Resource Access Manager (AWS RAM) para compartir las subredes de la VPC en Account-A con las cuentas miembro. AWS RAM permite compartir recursos de AWS, como subredes, con otras cuentas de AWS o dentro de una organización. Esto cumple con el requisito de que todas las cargas de trabajo se lancen en subredes de una VPC administrada centralmente y accesible por todas las cuentas, sin que las cuentas miembro puedan modificar los recursos de la VPC. Las otras opciones son incorrectas porque: Lanzar cargas de trabajo en cada cuenta miembro y recuperar los ID de subred con Fn::ImportValue no permite el lanzamiento directo en subredes compartidas de otra cuenta. Crear un Transit Gateway en la VPC de Account-A y configurar las cuentas miembro para usarlo es para interconexión de VPCs, no para compartir subredes directamente para el lanzamiento de recursos. Establecer el emparejamiento de VPC entre Account-A y cada cuenta miembro permite la comunicación entre VPCs, pero no permite que las cuentas miembro lancen recursos directamente en las subredes de la VPC de Account-A.