Design secure access to AWS resources

Cobaltine Insurance keeps claims data in an S3 bucket named cobaltine-claims-raw in its Production account (111122223333). A data science team in a separate Analytics account (444455556666) runs an AWS Glue job that must read from that bucket and write results to a bucket in the Analytics account. Cobaltine's security standard prohibits creating IAM users or sharing access keys between accounts, and the data science team requires that the job run under its single execution role with no role switching or credential handling in the job script.

Which solution meets these requirements?

1. AIn the Production account, create an IAM role that trusts the Analytics account and grants read access to cobaltine-claims-raw. Give the Glue job's execution role in the Analytics account permission to call sts:AssumeRole on that role.This cross-account role pattern would work technically, but it requires the job script to call sts:AssumeRole and juggle two credential sets, because the assumed Production role session has no access to the Analytics bucket. That violates the no-role-switching requirement; a bucket policy lets the one execution role do both.
2. BIn the Production account, add a bucket policy to cobaltine-claims-raw that grants s3:GetObject and s3:ListBucket to the Glue job's execution role ARN in the Analytics account, and give that execution role an identity policy allowing the same actions on the bucket.A resource-based bucket policy can grant a principal in another account access directly. Because the Glue job keeps its own execution role, it can read from the Production bucket and write to the Analytics bucket in the same session with no role switching.
3. CCreate an IAM user in the Production account with read access to the bucket and store its access keys in AWS Secrets Manager in the Analytics account for the Glue job to retrieve.This violates the stated prohibition on IAM users and shared access keys.
4. DEnable S3 Cross-Region Replication from cobaltine-claims-raw to a bucket in the Analytics account so the Glue job reads a local copy.Replication duplicates sensitive claims data into a second account and incurs storage and transfer cost; it is a data-movement solution, not an access-control solution, and the accounts may be in the same Region anyway.

Wrenfield Studios created a new member account in its organization and placed it in the Sandbox OU. The Sandbox OU has a service control policy that allows ec2:*, s3:*, and cloudwatch:* and nothing else. The platform team created an IAM role named SandboxUser in the new account with a trust policy for the developers, but attached no permissions policy to it. A developer who assumes the role cannot list S3 buckets and receives an AccessDenied error.

Why is the developer unable to list the buckets?

1. AThe SCP must be attached directly to the account rather than to the OU for it to grant permissions in the account.SCPs inherited from an OU apply to the accounts in that OU; attachment level is not the problem, and in any case SCPs do not grant permissions.
2. BThe SCP allows s3:* but the Deny for s3:ListAllMyBuckets in the FullAWSAccess policy takes precedence.FullAWSAccess is an Allow-all policy with no Deny statements; it does not block s3:ListAllMyBuckets.
3. CAn SCP only defines the maximum permissions available in the account; the role still needs an identity-based policy that allows s3:ListAllMyBuckets.SCPs act as a filter on what IAM policies can grant, but they never grant access by themselves. With no permissions policy attached to SandboxUser, there is no Allow for any action.
4. DRoles assumed from another account are not subject to SCPs, so the request falls back to the implicit deny.SCPs apply to all principals in the member account, including roles assumed by external users. The cause is the missing identity policy, not an SCP exemption.

Larkspur Health is moving from a single AWS account to a multi-account structure. The company wants a landing zone that creates new accounts from a standard template, applies preventive and detective guardrails, centralizes CloudTrail and AWS Config logs in a dedicated log archive account, and gives the security team a separate audit account. Larkspur has a small cloud team and wants to avoid building this from scratch.

Which solution will meet these requirements with the LEAST operational overhead?

1. ACreate an organization in AWS Organizations manually, then write CloudFormation StackSets for logging, Config rules, and IAM roles and apply them to each new account.This is the manual way to build a landing zone. It works, but the company has to design, build, and maintain all of the guardrails and account baselines itself.
2. BSet up AWS Control Tower, use its Account Factory to provision new accounts, and enable the preventive and detective controls Larkspur needs.Control Tower creates the organization, the log archive and audit accounts, centralized logging, and a library of controls implemented as SCPs and Config rules, and Account Factory provisions accounts with the baseline applied.
3. CUse AWS Service Catalog to publish a product that creates an account and attaches an AdministratorAccess policy to a shared IAM user.Service Catalog distributes approved templates but does not provide the organization structure, guardrails, or centralized logging, and a shared administrator user is a poor security practice.
4. DKeep a single account and separate workloads by VPC, using IAM policies with resource tags to simulate account boundaries.Tag-based policies in one account do not provide the blast-radius isolation, billing separation, or SCP-based preventive guardrails that a multi-account structure gives.

Oakhurst Bank operates 40 AWS accounts in an organization. A data-residency requirement states that resources in the Workloads organizational unit may be created only in eu-west-1 and eu-central-1. Account administrators must still be able to use global services such as IAM, AWS Organizations, Route 53, and CloudFront, and the requirement must apply even to users with AdministratorAccess in the member accounts. The bank wants a single control that does not need to be updated when new accounts join the OU.

Which solution meets these requirements?

1. AAttach a service control policy to the Workloads OU that denies all actions when aws:RequestedRegion is not eu-west-1 or eu-central-1, with a NotAction list that excludes the global services the administrators need.An SCP on the OU applies to every account in it, including future accounts, and overrides AdministratorAccess in the member accounts. The aws:RequestedRegion condition enforces the Region restriction and NotAction exempts global services whose API calls are made against us-east-1.
2. BAdd an IAM policy to the AdministratorAccess role in each member account that denies actions outside the two Regions.Per-account IAM policies can be edited or removed by the account administrators themselves and must be re-created in every new account, so they do not provide a single tamper-resistant control.
3. CEnable only eu-west-1 and eu-central-1 in the Region opt-in settings of the management account so that other Regions are unavailable to the organization.Region opt-in applies only to the newer opt-in Regions; the default-enabled Regions such as us-east-1 cannot be disabled this way, and the setting is per account rather than per OU.
4. DAttach the SCP to the management account so that it propagates down to all organizational units and member accounts.SCPs attached to the management account do not affect the management account's own principals, and SCPs attached to the root apply to every OU rather than just Workloads, which would restrict accounts the requirement does not cover.