SCS-C02 Identity and Access Management Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create a service role for CloudFormation in the pipeline account with a trust policy for the target account.

  Why it's wrong here

  A CloudFormation service role is an IAM role that CloudFormation assumes to perform stack operations in the account where the stack resides; its trust policy must grant access to the CloudFormation service principal (cloudformation.amazonaws.com), not to another AWS account. Creating such a role in the pipeline account with a trust policy for the target account does not enable cross-account access; instead, the pipeline must assume an IAM role in the target account via STS. The pipeline account's CloudFormation role would only manage stacks in the pipeline account, not the target account.

• ✗

  Store the target account root credentials in AWS Secrets Manager and retrieve them in the pipeline.

  Why it's wrong here

  Storing the target account's root user access keys in AWS Secrets Manager is a severe security anti-pattern because root credentials are long-lived, have unfettered administrative permissions, and cannot be scoped down or rotated safely. Retrieving them in the pipeline would require the pipeline role to have secretsmanager:GetSecretValue, but the pipeline would then use static, highly privileged credentials that violate IAM best practices and most compliance frameworks. Cross-account access should always rely on temporary credentials obtained via AWS STS AssumeRole, never on shared root keys.

• ✗

  Configure the pipeline's IAM role with a trust policy that allows the target account to access it.

  Why it's wrong here

  The pipeline's IAM role is designed to grant permissions to the pipeline service itself (for example, CodePipeline or CodeBuild), and its trust policy must identify the corresponding AWS service principal as the trusted entity. Adding the target account as a trusted principal in that trust policy would invert the trust relationship: it would allow the target account (or identities in it) to assume the pipeline role, not give the pipeline any access to the target account. The correct trust relationship is on the target-account role, which must trust the pipeline account to assume it.

• ✓

  Use AWS STS AssumeRole in the pipeline to obtain temporary credentials for the target account role.

  Why this is correct

  The pipeline must call the AWS Security Token Service (STS) AssumeRole API using the pipeline's existing IAM role or a dedicated deployment role, passing the ARN of the target-account role as the RoleArn parameter. STS then returns temporary, automatically expiring credentials (access key, secret key, and session token) that grant exactly the permissions defined in the target role's permissions policy. These temporary credentials can be passed to AWS SDK clients or exported as environment variables so that the deployment commands interact with the target account without human involvement or long-lived secrets.

• ✓

  Create an IAM role in the target account with a trust policy allowing the pipeline account to assume it.

  Why this is correct

  You must create an IAM role in the target account whose trust policy lists the pipeline account (or a specific pipeline role/account ID) as a Principal with sts:AssumeRole permission, and whose permissions policy grants the specific actions required for the deployment (such as CloudFormation, S3, or Lambda). This establishes a delegated administration pattern where the target account retains control over what the pipeline can do, and access is granted on a least-privilege basis. Combined with STS AssumeRole from the pipeline, this is the canonical secure architecture for cross-account CI/CD deployments.

Go deeper

Related to this question