A company uses AWS Organizations and Control Tower for governance and a Transit Gateway for multi-account VPC connectivity. The application team deployed a web app (Lambda + RDS) in an application account. DBAs in a separate DBA account centrally manage databases and use an EC2 instance in the DBA account to access an RDS instance in the application account. The application team stores DB credentials in AWS Secrets Manager in the application account and currently shares secrets manually with the DBAs. Secrets are encrypted with the default AWS-managed Secrets Manager key in the application account. Design a solution that gives the DBAs access to the database without manual secret sharing.

The correct solution uses IAM roles for secure cross-account access. An IAM role (DBA-Secret) in the application account is granted permission to read the secrets. Another IAM role (DBA-Admin) in the DBA account is given permission to assume the DBA-Secret role. By attaching DBA-Admin to the EC2 instance, DBAs can assume the DBA-Secret role, gaining temporary credentials to access the secrets without manual sharing. This is a standard and secure AWS pattern for delegated cross-account access. Using AWS RAM to share secrets directly (Option 1) is not supported; RAM shares resources like subnets or transit gateway attachments, not Secrets Manager secrets. Granting access to the KMS key (Option 3) is insufficient; the primary access control for Secrets Manager is through IAM policies on the secret itself, not just the encryption key. Using an SCP (Option 4) to allow access is incorrect; SCPs restrict permissions but cannot grant them across accounts.