AWS CodePipeline

47 questions

All types47 Multiple choice23 Multiple select10 Ordering14

A developer is configuring a basic continuous delivery pipeline in AWS CodePipeline to automate software releases. The pipeline must retrieve source code from an AWS CodeCommit repository, compile the project using AWS CodeBuild, and deploy it to an Amazon ECS service using AWS CodeDeploy. Arrange the following steps in the correct chronological order from first to last to complete a single pipeline execution.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of pipeline execution is: first, detecting the change in CodeCommit; second, retrieving the source files and storing them in Amazon S3; third, building the application using AWS CodeBuild; and finally, deploying the application to Amazon ECS using AWS CodeDeploy.

A pipeline execution in AWS CodePipeline flows sequentially through stages. First, CodePipeline detects a change in the source repository. Second, the source stage retrieves the code and stores it in Amazon S3 as an input artifact. Third, AWS CodeBuild compiles the code and generates the build output artifact. Lastly, AWS CodeDeploy uses the build artifact to update the Amazon ECS service.

Step-by-Step Solution

Detect change in the source repository

Pipeline execution is triggered.

AWS CodePipeline monitors the source repository for changes to start the release process automatically.

Retrieve source files and upload to the artifact store

Source artifact is created and stored in the pipeline's Amazon S3 bucket.

The files must be uploaded to the artifact store so they are accessible by downstream actions.

Execute the build stage action

A build output artifact is created.

AWS CodeBuild runs compile and packaging steps on the source artifact to generate the deployable artifact.

Execute the deploy stage action

The application is updated in the target environment.

AWS CodeDeploy consumes the build output artifact to update the Amazon ECS task definition and service.

Key Concept

AWS CodePipeline execution runs sequentially through stages (Source, Build, Deploy). Each stage processes input artifacts generated by previous stages and produces output artifacts for subsequent stages.

Estimated Time:45s

Question 2Question →

An enterprise application utilizes a release pipeline in AWS CodePipeline to automate deployments. The pipeline has a source stage in a development AWS account and must deploy a containerized application to an Amazon ECS cluster located in a separate production AWS account. During execution, the Deploy stage fails when trying to invoke the deployment action in the production account, returning an access denied error when attempting to assume the target role.

Which configuration is necessary to successfully authorize this cross-account deployment?

Modify the trust policy of the IAM role in the production account to allow the IAM role executing the pipeline in the development account to perform the sts:AssumeRole action.

Add a permissions policy statement to the target IAM role in the production account allowing the sts:AssumeRole action for the development pipeline's IAM role, without modifying its trust policy.

Create a secure string parameter in AWS Systems Manager Parameter Store containing the production account's credentials, enable automatic rotation, and inject them into the deployment stage.

Update the Amazon ECS Task Execution Role in the production account to grant the pipeline's service role direct permissions to deploy the container image.

Show answer & explanation

Answer: Modify the trust policy of the IAM role in the production account to allow the IAM role executing the pipeline in the development account to perform the sts:AssumeRole action.

Answer

Modify the trust policy of the IAM role in the production account to allow the IAM role executing the pipeline in the development account to perform the sts:AssumeRole action.

For AWS CodePipeline to perform deployments in a separate AWS account, it must assume an IAM role inside that target account. For the role assumption to succeed, the trust policy (assume role policy) of the target IAM role must be configured to trust the pipeline's IAM role in the source account, granting it the sts:AssumeRole permission.

Step-by-Step Solution

Identify the authentication failure context.

The failure occurs during a cross-account deployment stage when the source account's CodePipeline attempts to assume the target IAM role in the production account.

AWS CodePipeline requires cross-account role delegation using AWS Security Token Service (STS) to deploy across accounts.

Determine where the delegation of trust is configured.

The trust must be established on the target resource (the production IAM role) to allow assumption by the source entity.

An IAM role's trust policy dictates which external AWS accounts or IAM principals are permitted to assume it.

Modify the target role's trust policy.

Add the ARN of the development pipeline's IAM role (or the development account root) to the principal element of the production role's trust policy with the sts:AssumeRole action.

This establishes a secure cryptographic trust chain between the two AWS accounts.

Key Concept

Cross-Account Access in AWS CodePipeline via STS AssumeRole

Question 3Question →

A developer is configuring a cross-account continuous delivery pipeline in AWS CodePipeline. The pipeline is hosted in Account A and is designed to deploy a serverless application to Account B using AWS CloudFormation. The pipeline uses an Amazon S3 bucket in Account A to store pipeline artifacts. The deployment action in the Deploy stage fails with an error indicating that the CloudFormation role in Account B cannot access the deployment artifacts in the S3 bucket in Account A. The S3 bucket is currently encrypted using the default AWS managed key (aws/s3). Which configuration change is required to resolve this issue and allow successful deployment?

Configure the S3 bucket in Account A to use a customer managed key (CMK) in AWS KMS. Update the KMS key policy and the S3 bucket policy in Account A to grant read permissions to the CloudFormation execution role in Account B, and grant the role permissions to decrypt the KMS key.

Modify the trust policy of the CloudFormation execution role in Account B to directly allow the AWS CodePipeline service principal (codepipeline.amazonaws.com) to assume the role, and attach an inline policy to the role allowing S3 read actions on the Account A bucket.

Configure the pipeline to store the build artifacts and deployment templates in AWS Systems Manager Parameter Store as SecureString parameters, and configure the CloudFormation action in Account B to retrieve them.

Move the buildspec.yml file in the source repository from the root directory to the subdirectory containing the CloudFormation templates, and specify this new path in the CodePipeline deploy action settings.

Show answer & explanation

Answer: Configure the S3 bucket in Account A to use a customer managed key (CMK) in AWS KMS. Update the KMS key policy and the S3 bucket policy in Account A to grant read permissions to the CloudFormation execution role in Account B, and grant the role permissions to decrypt the KMS key.

Answer

For cross-account deployments in AWS CodePipeline, the deployment action in the target account must access the artifact S3 bucket in the source account. When using KMS encryption for the S3 bucket, you cannot use the default AWS-managed key (aws/s3) because its key policy cannot be modified to grant access to external accounts. A Customer Managed Key (CMK) must be created in the source account, and its key policy, along with the S3 bucket policy, must grant permissions to the target account's deployment role. The target role must also have permission to decrypt using that KMS key.

Step-by-Step Solution

Identify the cause of the cross-account S3 access failure.

The S3 bucket uses the default AWS-managed key (aws/s3) for encryption, which cannot be shared across different AWS accounts.

AWS-managed KMS keys do not allow modifications to their key policies to trust other AWS accounts.

Create and configure a Customer Managed Key (CMK) in AWS KMS.

A CMK is created in Account A with a key policy that allows the CloudFormation execution role in Account B to perform kms:Decrypt actions.

A Customer Managed Key allows policy customization, making it possible to grant cross-account decryption capabilities.

Update the S3 bucket policy and associate the CMK with the S3 bucket.

The S3 bucket in Account A is configured to use the new CMK, and its bucket policy is updated to allow S3 read actions (s3:GetObject, s3:GetBucketLocation) from the CloudFormation role in Account B.

Both the KMS key policy and the S3 bucket policy must allow cross-account access for the target role to successfully retrieve the artifacts.

Key Concept

Cross-account AWS CodePipeline S3 artifact access using KMS Customer Managed Keys (CMK)

Question 4Question →

A developer is configuring a release pipeline in AWS CodePipeline. The pipeline must retrieve a database password that requires automatic weekly rotation, and it must assume an IAM role in a target AWS account to deploy resources. Which of the following configuration steps are correct? (Select TWO.)

Select all that apply

Store the database password in AWS Secrets Manager, which natively supports automatic rotation of database credentials.

Store the database password in Systems Manager Parameter Store, as Parameter Store natively supports automatic rotation.

Configure the trust policy of the target IAM role to allow the CodePipeline service role to assume it.

Configure the permission policy of the target IAM role to authorize which external accounts can assume the role.

Create an IAM group and attach the CodePipeline service role to the group to manage cross-account permissions.

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager, which natively supports automatic rotation of database credentials.; Configure the trust policy of the target IAM role to allow the CodePipeline service role to assume it.

Answer

Store the database password in AWS Secrets Manager, which natively supports automatic rotation of database credentials, and configure the trust policy of the target IAM role to allow the CodePipeline service role to assume it.

Storing database credentials in AWS Secrets Manager is correct because it natively handles secrets and supports automatic weekly rotation. Additionally, configuring the trust policy of the target IAM role allows CodePipeline to assume the role and execute deployment actions in the target account.

Step-by-Step Solution

Determine the appropriate service for storing database credentials requiring rotation.

AWS Secrets Manager is chosen because it natively supports rotating secrets automatically.

This meets the requirement of storing a database password with automatic rotation.

Determine the proper method for establishing cross-account access.

Configure the trust policy of the target IAM role to allow the source account's CodePipeline service role to assume it.

Trust policies define who can assume an IAM role, which is required for cross-account execution.

Key Concept

AWS CodePipeline integrates with Secrets Manager for secret retrieval and uses cross-account IAM role assumptions defined via trust policies to perform deployments.

Question 5Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline within AWS Account A (Tooling Account). The pipeline must build and deploy a serverless application to AWS Account B (Production Account) using AWS CloudFormation. The deployment process requires a sensitive API authentication token that is generated during the build stage and must be rotated automatically on a weekly schedule. The deployment must adhere to the principle of least privilege. Which combination of configuration steps will meet these requirements?

Store the API token in AWS Secrets Manager in Account B and configure a weekly rotation schedule. In Account B, create an IAM role for the pipeline action with a permissions policy allowing AWS CloudFormation deployments and retrieval of the Secrets Manager secret. Edit the trust policy of this IAM role in Account B to allow the CodePipeline service role from Account A to perform sts:AssumeRole. In Account A, configure the pipeline by setting the RoleArn of the CloudFormation deploy action to the ARN of the IAM role in Account B.

Store the API token in AWS Systems Manager Parameter Store in Account B and configure a weekly rotation schedule. In Account B, create an IAM role for the pipeline action with a permissions policy allowing AWS CloudFormation deployments and decryption of the Parameter Store parameter. Edit the trust policy of this IAM role in Account B to allow the CodePipeline service role from Account A to perform sts:AssumeRole. In Account A, configure the pipeline by setting the RoleArn of the CloudFormation deploy action to the ARN of the IAM role in Account B.

Store the API token in AWS Secrets Manager in Account B and configure a weekly rotation schedule. In Account B, create an IAM role for the pipeline action with a trust policy that allows the AWS CloudFormation service principal to assume the role. Attach an IAM permissions policy to this role that allows the CodePipeline service role from Account A to perform sts:AssumeRole. In Account A, configure the pipeline by setting the RoleArn of the CloudFormation deploy action to the ARN of the IAM role in Account B.

Store the API token in AWS Systems Manager Parameter Store in Account B and configure a weekly rotation schedule. In Account B, create an IAM role for the pipeline action with a trust policy that allows the AWS CloudFormation service principal to assume the role. Attach an IAM permissions policy to this role that allows the CodePipeline service role from Account A to perform sts:AssumeRole. In Account A, configure the pipeline by setting the RoleArn of the CloudFormation deploy action to the ARN of the IAM role in Account B.

Show answer & explanation

Answer: Store the API token in AWS Secrets Manager in Account B and configure a weekly rotation schedule. In Account B, create an IAM role for the pipeline action with a permissions policy allowing AWS CloudFormation deployments and retrieval of the Secrets Manager secret. Edit the trust policy of this IAM role in Account B to allow the CodePipeline service role from Account A to perform sts:AssumeRole. In Account A, configure the pipeline by setting the RoleArn of the CloudFormation deploy action to the ARN of the IAM role in Account B.

Answer

Store the API token in AWS Secrets Manager in Account B, configure a weekly rotation schedule, configure the trust policy of the IAM role in Account B to allow CodePipeline in Account A to assume it, and reference this role ARN in the pipeline deploy action.

The correct option correctly identifies that AWS Secrets Manager is required for secrets needing native automatic rotation. It also correctly structures the cross-account deployment permissions: the IAM role in the target deployment account (Account B) must have a trust policy allowing the Tooling Account (Account A) pipeline service role to assume it, and this cross-account role ARN must be specified in the pipeline's deploy action configuration.

Step-by-Step Solution

Select the appropriate storage service for a sensitive token that requires automatic rotation.

AWS Secrets Manager is chosen because it natively supports automatic rotation (via AWS Lambda), whereas Systems Manager Parameter Store does not.

Ensures rotation requirements are met natively and cost-effectively without building custom rotation scripts.

Configure the cross-account IAM role in Account B (Production Account).

The role is created with permissions to deploy resources via CloudFormation and read the Secrets Manager secret. The trust policy of the role is edited to trust Account A's CodePipeline service role.

To allow cross-account access, the target account's role must trust the source account's principal to perform the sts:AssumeRole action.

Configure the CodePipeline action in Account A (Tooling Account).

The CloudFormation deploy action is updated to specify the RoleArn pointing to the IAM role in Account B.

This tells CodePipeline to assume the specified cross-account IAM role in Account B when executing the deploy stage.

Key Concept

Cross-account AWS CodePipeline deployments and secret management with native rotation.

Question 6Question →

A developer is configuring a continuous release pipeline in AWS CodePipeline for a web application. The pipeline must include a manual approval stage before deploying the application to production, which should notify the operations team. Additionally, the subsequent build and deployment stage in AWS CodeBuild requires a database API key that must be rotated automatically every 30 days. Which combination of steps should the developer perform to meet these requirements securely? (Select TWO.)

Select all that apply

Create an Amazon SNS topic, subscribe the operations team's email addresses, and associate the SNS topic ARN with the manual approval action in CodePipeline.

Store the database API key in AWS Secrets Manager, enable automatic rotation, and retrieve the secret in the CodeBuild buildspec file using the Secrets Manager integration.

Store the database API key in AWS Systems Manager Parameter Store as a SecureString parameter, configure automatic 30-day rotation on the parameter, and reference it in CodeBuild.

Modify the CodePipeline service role's trust policy to include the operations team's IAM user ARNs, enabling them to receive approval notifications directly.

Add the database API key plaintext value directly to the buildspec.yml file in the root of the source repository so CodeBuild can read it during the build.

Show answer & explanation

Answer: Create an Amazon SNS topic, subscribe the operations team's email addresses, and associate the SNS topic ARN with the manual approval action in CodePipeline.; Store the database API key in AWS Secrets Manager, enable automatic rotation, and retrieve the secret in the CodeBuild buildspec file using the Secrets Manager integration.

Answer

Create an Amazon SNS topic, subscribe the operations team's email addresses, and associate it with the manual approval action; and store the database API key in AWS Secrets Manager with automatic rotation enabled, retrieving it during the build phase.

To satisfy the requirements, the developer must use an Amazon SNS topic subscribed to the operations team's email addresses and link it to the manual approval action. For the secret requiring rotation, storing the key in AWS Secrets Manager with automatic rotation enabled satisfies the 30-day rotation requirement and can be securely retrieved by CodeBuild at runtime.

Step-by-Step Solution

Determine the mechanism to notify the operations team of manual approvals in CodePipeline.

Identify Amazon SNS as the supported service for manual approval action notifications.

CodePipeline manual approval actions natively integrate with Amazon SNS to publish notification messages.

Evaluate secret storage options for the database API key requiring automatic rotation.

Select AWS Secrets Manager as the appropriate service for secret rotation.

Secrets Manager provides native automatic rotation capabilities, unlike Systems Manager Parameter Store.

Configure the build execution step to retrieve the secret securely.

Reference the Secrets Manager secret dynamically inside the buildspec.yml file.

Retrieving the secret at runtime prevents hardcoding sensitive credentials in source code or project settings.

Key Concept

AWS CodePipeline manual approvals and secure secret rotation integration with CodeBuild

Question 7Question →

A developer is configuring a release pipeline in AWS CodePipeline. The pipeline contains a stage that must invoke an AWS Lambda function to perform deployment validation tests. The developer creates a new IAM role for the pipeline to interact with AWS resources. During the first execution of the pipeline, the run fails at the Lambda stage with an access denied error. The developer verifies that the IAM policy attached to the pipeline's service role explicitly grants the `lambda:InvokeFunction` permission. Which of the following configuration failures is preventing the pipeline from executing the Lambda function?

The IAM trust policy of the pipeline's service role does not allow the CodePipeline service principal (codepipeline.amazonaws.com) to assume the role.

The trust policy of the Lambda function's execution role does not list the CodePipeline service role as a trusted entity.

The pipeline is configured to retrieve the Lambda function's invocation token from AWS Systems Manager Parameter Store, which does not support the automatic credential rotation required by CodePipeline.

The Lambda function is defined under the Resources section of a CodeDeploy AppSpec file instead of being invoked directly as a stage action in CodePipeline.

Show answer & explanation

Answer: The IAM trust policy of the pipeline's service role does not allow the CodePipeline service principal (codepipeline.amazonaws.com) to assume the role.

Answer

The IAM trust policy of the pipeline's service role does not allow the CodePipeline service principal (codepipeline.amazonaws.com) to assume the role.

The correct answer is correct because AWS CodePipeline must assume the pipeline's service role to execute stage actions, such as invoking an AWS Lambda function. If the service role's trust policy does not explicitly permit the CodePipeline service principal (`codepipeline.amazonaws.com`) to perform the `sts:AssumeRole` action, CodePipeline cannot assume the role. As a result, the action will fail with an access denied error, regardless of whether the permission policy attached to the role has the `lambda:InvokeFunction` permission.

Step-by-Step Solution

Analyze the error message and current configurations.

The pipeline fails with an access denied error during the Lambda invocation stage, despite the pipeline's IAM role having permissions for `lambda:InvokeFunction`.

This indicates that CodePipeline cannot successfully utilize the role, pointing to an issue with role assumption rather than missing execution permissions.

Verify how AWS CodePipeline interacts with IAM roles.

AWS CodePipeline requires a trust relationship (trust policy) to assume the service role associated with the pipeline execution.

An IAM role cannot be assumed by an AWS service unless that service is defined as a trusted entity in the role's trust policy.

Identify the missing configuration.

The trust policy of the role must include the `codepipeline.amazonaws.com` service principal to allow the service to perform the `sts:AssumeRole` operation.

Correcting this trust policy resolves the access denied issue and allows CodePipeline to invoke the Lambda function.

Key Concept

AWS CodePipeline requires a properly configured IAM trust policy on its service role to allow the service principal to assume the role and execute stage actions.

Estimated Time:1m 30s

Question 8Question →

A developer is implementing a cross-account continuous delivery pipeline in AWS CodePipeline. The pipeline is located in Account A and uses an Amazon S3 bucket in Account A to store artifacts. The deployment stage is configured to deploy resources into Account B using an AWS CloudFormation action. During pipeline execution, the CloudFormation action in Account B fails with an Access Denied error when trying to retrieve the input artifact zip file from the S3 bucket in Account A. The IAM role used for the CloudFormation deployment in Account B has been granted read permission to the S3 bucket in Account A, and the S3 bucket policy in Account A permits access from Account B's deployment role.

Which configuration change is required to resolve this deployment failure?

Update the IAM trust policy of the CodePipeline service role in Account A to allow the deployment IAM role in Account B to assume it, and configure AWS Systems Manager Parameter Store in Account B to cache the S3 credentials.

Configure the S3 bucket in Account A to use a customer managed AWS KMS key instead of the default S3 managed key, grant the deployment IAM role in Account B permission to use the KMS key, and update the KMS key policy in Account A to trust Account B's deployment role.

Store the S3 bucket access credentials as a secret in AWS Secrets Manager in Account A, and configure the deployment IAM role in Account B to retrieve the secret by making a call to AWS Systems Manager Parameter Store.

Configure the deployment IAM role in Account B to trust the CodePipeline service role in Account A by updating its trust policy, and configure the CodePipeline service role in Account A to assume the deployment IAM role in Account B without a KMS key.

Show answer & explanation

Answer: Configure the S3 bucket in Account A to use a customer managed AWS KMS key instead of the default S3 managed key, grant the deployment IAM role in Account B permission to use the KMS key, and update the KMS key policy in Account A to trust Account B's deployment role.

Answer

For cross-account deployments in AWS CodePipeline, artifacts stored in the Amazon S3 bucket must be encrypted using a customer managed AWS KMS key. The default S3 managed key (aws/s3) cannot be shared cross-account because its key policy cannot be modified to grant access to external IAM roles. By configuring a customer managed KMS key, the developer can explicitly grant the deployment IAM role in the destination account permission to decrypt the artifacts.

Step-by-Step Solution

Determine why the access is denied despite correct IAM and bucket policies.

The default S3 encryption key (aws/s3) is managed by AWS and its policy cannot be modified to grant cross-account permissions.

Identify the root cause of cross-account decryption failures in CodePipeline.

Create a customer managed AWS KMS key in Account A to encrypt the S3 artifact bucket.

The S3 bucket's default encryption is updated to use the new customer managed key.

Allows custom key policies to be configured for cross-account access.

Update the KMS key policy in Account A and the IAM deployment role in Account B.

The deployment role in Account B can now decrypt the artifacts when CloudFormation runs in Account B.

Establishes secure, cross-account access to the build artifacts.

Key Concept

AWS CodePipeline Cross-Account Deployments and Artifact Encryption

Estimated Time:2m 30s

Question 9Question →

A developer is configuring a cross-account deployment pipeline in AWS CodePipeline. The pipeline is located in Account A (the tooling account) and must deploy a containerized application to Amazon ECS in Account B (the target account). The pipeline's artifact store is an Amazon S3 bucket in Account A, which is encrypted with an AWS KMS Customer Managed Key (CMK) also located in Account A.

To successfully configure and run this pipeline, the developer needs to set up the necessary cross-account IAM roles, resource policies, and pipeline action settings.

What is the correct chronological sequence of steps required to successfully configure and execute this cross-account deployment?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first, create the target deployment IAM role in Account B; second, update the KMS key policy and S3 bucket policy in Account A; third, configure the deploy action in the Account A pipeline; fourth, run the pipeline execution; and fifth, decrypt the artifact and deploy to Amazon ECS in Account B.

The correct sequence begins with creating the IAM role in Account B so that its ARN is valid. Then, policies in Account A (S3 and KMS) are updated to reference this ARN. Next, the pipeline deploy action is modified to use this role. Finally, the pipeline is executed, assuming the role, downloading, and decrypting the artifact to complete the deployment.

Step-by-Step Solution

Create the IAM role in Account B with a trust policy for Account A's CodePipeline service role.

The target deployment role exists, establishing a valid ARN for resource policy references.

AWS API validates principal ARNs in resource policies; the role must exist before it can be referenced elsewhere.

Update the KMS key policy and S3 bucket policy in Account A.

The Account B role is granted permissions to read from the artifact bucket and decrypt using the CMK.

Allows the cross-account deployment role to access the pipeline's encrypted artifacts.

Update the pipeline definition in Account A to specify the deploy action's roleArn.

The deploy action is configured to assume the Account B role during execution.

Tells CodePipeline which role to assume when running the deployment phase.

Trigger the pipeline execution.

CodePipeline assumes the Account B role and retrieves the artifact from S3.

Initiates the cross-account action execution workflow.

Decrypt the artifact and update the Amazon ECS service.

The application is successfully deployed to Account B.

Executes the final deployment step using the assumed role permissions and decrypted content.

Key Concept

Cross-account pipeline deployments with AWS KMS-encrypted artifact stores require strict ordering of IAM role creation, resource policy configuration (KMS and S3), and pipeline definition updates.

Estimated Time:3m 0s

Question 10Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline to deploy a containerized application to Amazon ECS. The application requires access to a database password that must be rotated automatically every 30 days. The pipeline must deploy the new version to ECS with zero downtime, using a secure method to supply the database password to the container without exposing it in plaintext in the pipeline artifacts or source code.

Which configuration should the developer implement?

Store the password in AWS Secrets Manager with automatic rotation enabled. In the Amazon ECS task definition, reference the secret using its ARN in the secrets section. Use AWS CodeDeploy within CodePipeline to perform a Blue/Green deployment for the ECS service.

Store the password as a SecureString parameter in Systems Manager Parameter Store with automatic rotation enabled. In the CodePipeline build stage, retrieve the parameter and pass it as an output artifact to the ECS deployment stage. Use AWS CodeDeploy to perform a Canary deployment.

Store the password in AWS Secrets Manager with automatic rotation enabled. Update the ECS Task Execution Role's trust policy to allow the secretsmanager.amazonaws.com service principal to assume the role. Reference the secret ARN in the task definition environment variables. Use AWS CodeDeploy within CodePipeline to run a Blue/Green deployment.

Store the password in AWS Secrets Manager with automatic rotation enabled. In the CodePipeline source stage, add the password directly to the container environment variables in the AppSpec file. Use AWS CodeDeploy within CodePipeline to perform an All-at-Once deployment to replace the running ECS tasks.

Show answer & explanation

Answer: Store the password in AWS Secrets Manager with automatic rotation enabled. In the Amazon ECS task definition, reference the secret using its ARN in the secrets section. Use AWS CodeDeploy within CodePipeline to perform a Blue/Green deployment for the ECS service.

Answer

The correct answer correctly identifies AWS Secrets Manager as the appropriate service for credentials requiring automatic rotation. It correctly uses the ECS task definition 'secrets' section to securely inject the secret into the container at runtime, and uses AWS CodeDeploy Blue/Green deployment to ensure a zero-downtime deployment.

Step-by-Step Solution

Store and secure the secret

The database password is saved in AWS Secrets Manager, and automatic rotation is configured for every 30 days.

Secrets Manager natively supports automatic rotation, meeting the requirement, while Systems Manager Parameter Store does not.

Configure ECS task definition integration

The ECS task definition references the Secrets Manager ARN in the 'secrets' parameter, rather than placing it in plaintext environment variables.

This enables the ECS agent to securely retrieve the password and inject it into the container at launch time without exposing it in the pipeline definition.

Define the deployment strategy in CodePipeline

A Blue/Green deployment is set up using AWS CodeDeploy as a deploy action in CodePipeline.

A Blue/Green deployment provisions a new task set and routes traffic traffic incrementally or all-at-once to the new tasks, ensuring zero downtime and providing an automated rollback path if the deployment fails.

Key Concept

AWS CodePipeline integration with ECS and AWS Secrets Manager for secure container deployment.

Question 11Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline. During the pipeline execution, the pipeline fails at the transition to a deployment stage with an access denied error indicating that the pipeline cannot assume the service role. Which of the following is the most likely cause of this failure?

The IAM service role assigned to the pipeline has a trust policy that does not list codepipeline.amazonaws.com as a trusted entity.

The IAM service role lists codepipeline.amazonaws.com in the identity-based permissions policy rather than in the trust policy.

The pipeline is attempting to retrieve a database connection string from Systems Manager Parameter Store, which fails because Parameter Store cannot rotate credentials.

The pipeline is unable to parse the build configuration because the buildspec.yml file is placed in a subdirectory of the source repository rather than the root directory.

Show answer & explanation

Answer: The IAM service role assigned to the pipeline has a trust policy that does not list codepipeline.amazonaws.com as a trusted entity.

Answer

The IAM service role assigned to the pipeline must have a trust policy that explicitly lists codepipeline.amazonaws.com as a trusted entity.

The correct option is correct because AWS CodePipeline requires an IAM service role to execute pipeline actions on your behalf. The service role's trust policy must declare codepipeline.amazonaws.com as a trusted entity so that the pipeline service can assume the role and obtain temporary credentials.

Step-by-Step Solution

Analyze the error message regarding the pipeline's inability to assume the designated service role.

Identify that the issue is related to IAM role assumption permissions.

The error specifically mentions that CodePipeline is denied access when attempting to assume the service role.

Review the trust policy of the IAM service role assigned to AWS CodePipeline.

Determine if the service principal codepipeline.amazonaws.com is declared as a trusted entity.

Without the correct service principal in the trust policy, the AWS Security Token Service (STS) will block CodePipeline from assuming the role.

Verify that the permissions policy is separate from the trust policy.

Ensure permissions policies define resource access, whereas the trust policy dictates who can assume the role.

Misplacing trust declarations in the permissions policy is a common configuration mistake that results in access denied errors.

Key Concept

AWS CodePipeline Service Roles and IAM Trust Policies

Question 12Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline to automate the release of a containerized web application. The pipeline needs to retrieve source code, build a Docker image, deploy the application to Amazon ECS, and verify its status. Arrange the pipeline actions in the correct chronological sequence from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence of pipeline actions is: retrieve source code using AWS CodeCommit, build the Docker image using AWS CodeBuild, deploy the application using AWS CodeDeploy, and run integration tests using AWS Lambda.

The correct order follows the standard pipeline design: first obtaining source code (Source), compiling and producing the artifact (Build), deploying the artifact to the target platform (Deploy), and finally validating the live deployment (Test/Invoke).

Step-by-Step Solution

Trigger the pipeline by obtaining source files.

Source code is packaged as a source artifact and stored in the CodePipeline artifact bucket.

Subsequent compilation and packaging require access to the raw source code.

Pass the source artifact to CodeBuild to construct the build output.

A Docker image is built, pushed to Amazon ECR, and a build artifact containing the task definition template is created.

Deployment actions require a built container image and configuration templates to proceed.

Pass the build artifact to CodeDeploy to update Amazon ECS.

The target ECS service initiates a rolling update or green/blue deployment using the new task definition.

The application must be deployed to the runtime environment before it can be verified or accessed by clients.

Invoke AWS Lambda to run post-deployment validation tests.

Integration tests run against the live endpoint, and CodePipeline receives a success or failure status signal.

Post-deployment checks verify that the live system behaves correctly after changes are applied.

Key Concept

AWS CodePipeline Stage and Action Sequencing

Question 13Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline to deploy a serverless web application. The pipeline needs to pause automatically after the test stage and wait for a QA manager to review the test results before deploying to the production stage. Which of the following is the correct configuration to implement this manual approval step?

Add a manual approval action to a stage in the pipeline before the production deployment action, and optionally configure an Amazon SNS topic for notifications.

Store the approval state as a SecureString parameter in Systems Manager Parameter Store, and write a script in the build stage to poll for its value.

Modify the trust policy of the IAM service role for CodePipeline to allow the QA manager's IAM user to assume the role and resume the pipeline.

Place a build spec file in a subdirectory of the source repository with instructions to pause the CodeBuild container execution until an approval webhook is called.

Show answer & explanation

Answer: Add a manual approval action to a stage in the pipeline before the production deployment action, and optionally configure an Amazon SNS topic for notifications.

Answer

Add a manual approval action to a stage in the pipeline before the production deployment action, and optionally configure an Amazon SNS topic for notifications.

The correct answer provides the standard, native method for introducing a human review step in AWS CodePipeline. The Manual Approval action type natively pauses the pipeline execution without consuming compute resources, and integrates with Amazon SNS to notify the reviewers.

Step-by-Step Solution

Identify the pipeline requirement for pausing execution for a human reviewer.

The requirement is a manual approval gate before production deployment.

Understanding the design requirements helps select the native AWS CodePipeline feature meant for this purpose.

Evaluate native CodePipeline features for approvals versus custom scripting.

CodePipeline provides a built-in 'Manual Approval' action type that halts transition natively.

Using native actions is more cost-effective, secure, and easier to maintain than custom polling mechanisms.

Verify correct configuration details for the Manual Approval action.

A manual approval action is added to a pipeline stage, with an optional SNS topic to notify the QA team.

Configuring SNS ensures the team is proactively alerted when an approval is pending.

Key Concept

AWS CodePipeline manual approval actions allow a pipeline execution to be paused at a specific stage until approval is received.

Question 14Question →

An organization has a deployment pipeline configured in AWS CodePipeline in Account A. The pipeline needs to deploy a containerized application to Amazon ECS in Account B. The developer creates a cross-account deployment IAM role in Account B. Which configuration must be implemented to allow the pipeline in Account A to assume this role and perform the deployment?

Attach an IAM permissions policy to the role in Account B that grants the sts:AssumeRole action to the CodePipeline service role in Account A, while keeping the trust policy of the role restricted to local services in Account B.

Store the AWS access keys of an IAM user from Account B as a SecureString parameter in AWS Systems Manager Parameter Store in Account A, and configure CodePipeline to retrieve these credentials at runtime.

Configure the trust policy of the IAM role in Account B to allow the CodePipeline service role in Account A to perform the sts:AssumeRole action, and configure the deployment action in Account A to use this role ARN.

Configure the Amazon ECS Task Execution Role in Account B to trust the CodePipeline service role in Account A, enabling the container agent to pull the deployment artifacts directly.

Show answer & explanation

Answer: Configure the trust policy of the IAM role in Account B to allow the CodePipeline service role in Account A to perform the sts:AssumeRole action, and configure the deployment action in Account A to use this role ARN.

Answer

For cross-account deployments, the deployment action in Account A's pipeline must assume an IAM role in Account B. This is achieved by adding a trust policy to the role in Account B that allows the pipeline's service role in Account A to perform the sts:AssumeRole action. The deployment action in the pipeline is then configured to use the ARN of the role in Account B.

Step-by-Step Solution

Identify the mechanism AWS CodePipeline uses to interact with resources in a different AWS account.

Cross-account access in AWS requires role assumption (sts:AssumeRole) rather than static credentials.

Using IAM roles avoids the security risks associated with managing static access keys.

Determine where to configure the trust relationship and how the role is assumed.

The trust policy must be configured on the target role in Account B to trust the pipeline's role in Account A.

Trust policies specify which external entities are allowed to assume the role.

Specify the role in the pipeline action configuration.

The deployment action in Account A's pipeline is updated to reference the target role's ARN in Account B.

This tells CodePipeline which role to assume when executing that specific action.

Key Concept

AWS CodePipeline cross-account resource deployment using IAM roles and trust policies.

Question 15Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline. The pipeline has three stages:
1. Source: An Amazon S3 source action.
2. BuildAndTest: A stage containing three actions: a CodeBuild build action with `runOrder: 1`, a CodeBuild linting action with `runOrder: 1`, and a CodeBuild unit test action with `runOrder: 2` that requires the output artifact of the build action.
3. Deploy: An AWS Elastic Beanstalk deploy action.

When a new code revision is uploaded to the Amazon S3 source bucket, in what chronological order does AWS CodePipeline process the actions and transitions for a successful execution? Arrange the steps from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence is: first, the source action retrieves the revision and uploads it to the artifact store; second, the build and lint actions run concurrently; third, the build action completes and uploads its output artifact; fourth, the unit test action runs using the build output; and finally, the pipeline transitions to the Deploy stage.

AWS CodePipeline processes executions stage-by-stage. Within a stage, actions with the same runOrder value (such as the build and lint actions, both with runOrder 1) are executed in parallel. Actions with a higher runOrder (such as the unit test action with runOrder 2) will wait to execute until all actions with lower runOrder values have successfully completed. Furthermore, any output artifacts required as inputs by subsequent actions must be uploaded before those actions can start. Finally, the pipeline only transitions to the next stage (Deploy) once all actions in the current stage (BuildAndTest) have completed successfully.

Step-by-Step Solution

Analyze stage boundaries and action execution sequence.

Identify that the Source stage must complete first, creating the initial source artifact.

AWS CodePipeline is artifact-driven; subsequent stages cannot start without the input artifact from the source stage.

Determine execution order of parallel actions in the BuildAndTest stage.

Identify that the build action and linting action run concurrently.

Actions within the same stage that share the same runOrder value (in this case, 1) are executed in parallel.

Identify the transition criteria between runOrder levels.

Recognize that the unit test action (runOrder 2) must wait for all runOrder 1 actions to finish and the build output artifact to be uploaded.

CodePipeline executes actions sequentially based on runOrder. An action with runOrder 2 starts only after all runOrder 1 actions complete and its required input artifacts are available.

Determine when the stage transitions to the next stage.

Confirm that the Deploy stage starts after the unit test action completes.

A pipeline transition to a subsequent stage occurs only when all actions in the preceding stage have executed successfully.

Key Concept

AWS CodePipeline execution order, action runOrder concurrency, and stage transition logic.

Question 16Question →

A developer is configuring a simple release pipeline in AWS CodePipeline. The pipeline has a source stage, a build stage using AWS CodeBuild, and a deployment stage using AWS CodeDeploy. The developer needs to pass the compiled build output from the build stage to the deployment stage.

How should the developer configure the pipeline to transfer these files between the stages?

Define an output artifact in the build stage action, and reference it as an input artifact in the deployment stage action.

Store the build output files in AWS Systems Manager Parameter Store during the build stage, and retrieve them during the deployment stage.

Write the build output files to a temporary directory and configure the IAM trust policy of the build role to allow the deployment role to assume it and pull the files.

Hardcode IAM user access keys in the build environment variables to write the build outputs directly to the deployment environment.

Show answer & explanation

Answer: Define an output artifact in the build stage action, and reference it as an input artifact in the deployment stage action.

Answer

Define an output artifact in the build stage action, and reference it as an input artifact in the deployment stage action.

AWS CodePipeline manages the flow of data between stages through input and output artifacts. When a stage like CodeBuild runs, it can package its output into a ZIP file and upload it to the pipeline's S3 artifact bucket as an output artifact. Subsequent stages, such as CodeDeploy, can then download this ZIP file by referencing it as an input artifact.

Step-by-Step Solution

Identify the standard mechanism in AWS CodePipeline for transferring files (like build outputs) between stages.

CodePipeline uses artifacts (input and output) backed by an Amazon S3 bucket to share files across pipeline actions.

This maintains statelessness and isolation between stage execution environments.

Configure the source or build stage to produce an output artifact.

The build stage (CodeBuild) writes the compiled output files to a zip file in the pipeline S3 bucket, registered as an output artifact.

This makes the build artifacts available to downstream stages.

Configure the deployment stage to consume the artifact.

The deployment stage (CodeDeploy) specifies the output artifact from the build stage as its input artifact.

This allows CodeDeploy to download the correct files from the pipeline S3 bucket to execute the deployment.

Key Concept

AWS CodePipeline uses input and output artifacts to share files between pipeline actions and stages.

Question 17Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline in Account A ( $111122223333$ ) to automate deployments to Account B ( $444455556666$ ) using AWS CloudFormation. The pipeline fails during the Deploy stage with an access denied error when attempting to assume the deployment IAM role in Account B. Additionally, the CloudFormation template must retrieve a database password that requires automatic rotation every $30$ days. Which combination of actions should the developer take to resolve the deployment failure and meet the security requirements?

Update the trust policy of the deployment IAM role in Account B to allow the CodePipeline service role of Account A to perform the sts:AssumeRole action. Store the database password in AWS Secrets Manager and configure automatic rotation.

Update the permissions policy of the deployment IAM role in Account B to allow the CodePipeline service principal to assume the role. Store the database password in Systems Manager Parameter Store and implement custom rotation logic.

Update the trust policy of the deployment IAM role in Account B to trust the global CodePipeline service principal (codepipeline.amazonaws.com). Store the database password in Systems Manager Parameter Store and enable the parameter rotation policy.

Update the permissions policy of the CodePipeline service role in Account A to allow trust from Account B. Store the database password in AWS Secrets Manager and configure automatic rotation.

Show answer & explanation

Answer: Update the trust policy of the deployment IAM role in Account B to allow the CodePipeline service role of Account A to perform the sts:AssumeRole action. Store the database password in AWS Secrets Manager and configure automatic rotation.

Answer

The correct action is to update the trust policy of the target IAM role in Account B to allow Account A's CodePipeline service role to perform the sts:AssumeRole action, and to store the credentials in AWS Secrets Manager which natively handles automatic rotation. This properly satisfies both cross-account trust requirements and credential lifecycle security rules.

Step-by-Step Solution

Configure cross-account IAM role assumption.

The Deploy action in Account A's CodePipeline can now assume the IAM role in Account B to create or update the CloudFormation stack.

To deploy resources across AWS accounts, the CodePipeline service role in the source account must be granted permission to assume a role in the destination account. The destination account's role must trust the source role via its trust policy.

Select the correct credential storage service.

AWS Secrets Manager is selected to store the database password.

AWS Secrets Manager provides native, out-of-the-box support for database credential rotation, whereas Systems Manager Parameter Store does not.

Key Concept

Cross-account pipeline deployments and secret rotation management.

Question 18Question →

A developer is configuring a standard release pipeline in AWS CodePipeline to automate deployment. The pipeline must pull source code from an AWS CodeCommit repository, run tests and compile the code using AWS CodeBuild, require a manual sign-off from the quality assurance team, and finally deploy the application to AWS Elastic Beanstalk.

Arrange the actions in the correct sequence of execution from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of actions in the pipeline is: Source action (AWS CodeCommit), Build action (AWS CodeBuild), Manual approval action, and Deploy action (AWS Elastic Beanstalk).

AWS CodePipeline processes stages sequentially. The pipeline must first fetch the source code, compile and test it in the build phase, pause for manual verification, and finally deploy the verified package.

Step-by-Step Solution

Retrieve the source code from AWS CodeCommit.

The latest revision of the source code is retrieved and package artifacts are created.

Subsequent stages require the source code to perform builds and deployments.

Trigger the AWS CodeBuild environment to compile the application and run unit tests.

The application code is verified and a deployment package is generated.

Building the application generates the necessary artifacts that need to be reviewed and deployed.

Halt the pipeline for a Manual Approval action.

The pipeline execution pauses, and a notification is sent to the QA team for review.

This guarantees that the built artifacts are verified and approved before they reach the production environment.

Deploy the application using the AWS Elastic Beanstalk deployment action.

The verified application version is deployed to the Elastic Beanstalk environment.

Deploying is the final step in the pipeline after the application has been built and approved.

Key Concept

AWS CodePipeline action execution order

Question 19Question →

A developer is configuring a deployment pipeline in AWS CodePipeline to deploy a serverless application across two AWS accounts. The pipeline resides in Account A, and the application must be deployed to Account B using an AWS CloudFormation action in the deploy stage. The pipeline execution fails at the deploy stage with an access denied error when attempting to assume the deployment IAM role created in Account B.

How should the developer configure the IAM policies to successfully allow the pipeline in Account A to assume the deployment role in Account B?

Configure the trust policy of the deployment role in Account B to allow the sts:AssumeRole action from the CodePipeline service role in Account A, and grant the CodePipeline service role in Account A permission to call sts:AssumeRole on the deployment role in Account B.

Attach an identity-based IAM policy to the CodePipeline service role in Account A that allows the sts:AssumeRole action on the deployment role in Account B, as cross-account permissions do not require trust policies when initiated from a managed pipeline service role.

Create an IAM user in Account B, generate long-lived access keys, and store them as a secure parameter in AWS Systems Manager Parameter Store with automatic rotation configured, then reference the parameter in the pipeline configuration.

Add an aws sts assume-role command to the buildspec.yml file in the source repository to authenticate as Account B, and configure the CloudFormation deployment action to execute using the resulting temporary credentials.

Show answer & explanation

Answer: Configure the trust policy of the deployment role in Account B to allow the sts:AssumeRole action from the CodePipeline service role in Account A, and grant the CodePipeline service role in Account A permission to call sts:AssumeRole on the deployment role in Account B.

Answer

The correct option correctly establishes two-way trust for cross-account role assumption. The trust policy of the target role in Account B must trust the CodePipeline service role in Account A, and the CodePipeline service role must have an identity-based policy allowing it to assume the target role in Account B.

Step-by-Step Solution

Configure the trust policy in the target account (Account B)

The deployment IAM role in Account B is updated to list the AWS CodePipeline service role ARN from Account A as a trusted principal that can perform sts:AssumeRole.

Establishing trust in the target account's role is mandatory for any cross-account access to succeed.

Configure the permissions policy in the source account (Account A)

An identity-based policy is attached to the CodePipeline service role in Account A allowing the sts:AssumeRole action on Account B's deployment role ARN.

The source principal must have explicit permission to assume the external role.

Reference the target role in the pipeline configuration

The pipeline deploy stage action configuration is updated with the roleArn parameter pointing to the target deployment role in Account B.

This instructs CodePipeline to assume the cross-account role when executing the CloudFormation action.

Key Concept

Cross-account role assumption in AWS CodePipeline

Question 20Question →

A developer is managing a release pipeline in AWS CodePipeline that contains Source, Build, and Deploy stages. The developer wants to temporarily prevent new builds from automatically entering the Deploy stage while a production issue is being investigated, without stopping or deleting the pipeline. Which action should the developer take to meet this requirement?

Modify the trust policy of the CodePipeline service role to deny the permissions required to run the Deploy stage.

Disable the transition between the Build stage and the Deploy stage in CodePipeline.

Store a configuration parameter in AWS Systems Manager Parameter Store to control the Deploy stage status.

Modify the KMS key policy for the artifact S3 bucket to deny decryption rights to the Deploy stage action.

Show answer & explanation

Answer: Disable the transition between the Build stage and the Deploy stage in CodePipeline.

Answer

Disable the transition between the Build stage and the Deploy stage in CodePipeline.

Disabling the transition between stages in AWS CodePipeline prevents executions from moving from the upstream stage (Build) to the downstream stage (Deploy). This is the standard, built-in feature designed specifically for this purpose, allowing executions to compile and build while holding them before the deploy phase.

Step-by-Step Solution

Identify the requirement to temporarily halt the flow of executions into a specific stage without disabling the upstream stages or deleting the pipeline.

Recognized that the pipeline transition between the Build and Deploy stages needs to be controlled.

This isolates the Deploy stage from new incoming changes while allowing build testing to continue.

Evaluate AWS CodePipeline features for controlling pipeline flow and execution transitions between stages.

Identified that disabling stage transitions is the built-in mechanism for this use case.

Stage transitions can be enabled or disabled dynamically without changing permissions or configuration store parameters.

Select the option to disable the transition between the Build stage and the Deploy stage, which cleanly pauses executions at the boundary.

Correctly determined the operational action to resolve the scenario.

This is the most efficient and native method provided by CodePipeline.

Key Concept

AWS CodePipeline Stage Transitions

Page 1 / 3Next

AWS CodePipeline

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept