Está convirtiendo un entorno AWS no productivo, efímero y existente en una plantilla de CloudFormation. El entorno incluye una instancia EC2 cuyo perfil de instancia le permite asumir un rol en una cuenta principal. Recreó el rol en un stack de CloudFormation (usando el mismo nombre de rol) y desplegó el stack en la cuenta secundaria. Después, la instancia EC2 no puede asumir el rol en la cuenta principal debido a permisos insuficientes. ¿Qué debe hacer para solucionar el problema?

La respuesta correcta es actualizar la política de confianza del rol en la cuenta principal. Cuando se recrea un rol en CloudFormation, incluso con el mismo nombre, su ARN (Amazon Resource Name) cambia porque incluye un identificador único. La política de confianza del rol en la cuenta principal debe especificar el ARN exacto del rol de instancia de EC2 que intenta asumir el rol. Al actualizar la política de confianza para incluir el nuevo ARN del rol de instancia de EC2, se restablece la capacidad de la instancia para asumir el rol. Las otras opciones son incorrectas porque: Modificar la política de confianza para permitir sts:AssumeRole para el principal root de la cuenta secundaria otorgaría permisos excesivos y no específicos, lo cual es una mala práctica de seguridad. Especificar CAPABILITYNAMEDIAM o CAPABILITYIAM al actualizar el stack de CloudFormation solo es relevante para permitir que CloudFormation cree recursos IAM con nombres personalizados o que tengan permisos IAM, pero no soluciona el problema de la política de confianza entre cuentas.