Deployment

376 questions

All types376 Multiple choice191 Multiple select171 Ordering14

A developer is configuring an AWS CodeDeploy deployment group for an in-place deployment of a web application to Amazon EC2 instances. The deployment must automatically revert to the last known successful version if the new deployment fails or if application error rates exceed a specific threshold. Additionally, the developer needs to ensure that any temporary files left by a failed deployment are cleaned up during the rollback process.

Which of the following configurations should the developer implement to meet these requirements? (Select TWO.)

Select all that apply

Enable automatic rollbacks in the CodeDeploy deployment group settings for deployment failures, and configure a CloudWatch alarm to trigger a rollback when application error rates exceed the threshold.

Implement the cleanup script within the BeforeInstall lifecycle hook of the application's AppSpec file, because CodeDeploy rolls back by executing a new deployment of the last successful revision.

Add a Rollback hook to the hooks section of the appspec.yml file to execute a script that automatically deletes temporary files when a rollback is initiated.

Attach a service role to the CodeDeploy agent on the EC2 instances with a trust policy that permits the sns:Publish action for rollback alerts.

Store the cleanup script in AWS Systems Manager Parameter Store as a secure parameter, and reference it under the resources section of the appspec.yml file.

Show answer & explanation

Answer: Enable automatic rollbacks in the CodeDeploy deployment group settings for deployment failures, and configure a CloudWatch alarm to trigger a rollback when application error rates exceed the threshold.; Implement the cleanup script within the BeforeInstall lifecycle hook of the application's AppSpec file, because CodeDeploy rolls back by executing a new deployment of the last successful revision.

Answer

Enable automatic rollbacks in the CodeDeploy deployment group settings for deployment failures and CloudWatch alarm states, and implement cleanup logic in the BeforeInstall hook of the AppSpec file because CodeDeploy performs a rollback by initiating a new deployment of the last successful revision.

The correct configurations are to enable automatic rollbacks in the CodeDeploy deployment group for both deployment failures and when a configured CloudWatch alarm (tracking error rates) goes into the ALARM state. Furthermore, because CodeDeploy executes a rollback by initiating a new deployment of the last successful revision, the cleanup logic must be placed in a standard lifecycle hook such as BeforeInstall of that revision to ensure any leftover artifacts from the failed deployment are deleted before files are copied.

Step-by-Step Solution

Configure rollback behaviors on the deployment group

Automatic rollbacks are enabled for deployment failures and CloudWatch alarms monitoring error rate thresholds.

This natively automates the rollback process when a failure is detected or when application metrics degrade.

Analyze how CodeDeploy executes rollbacks

CodeDeploy handles rollbacks by running a brand new deployment of the previous successful revision.

Understanding this flow reveals that there is no custom Rollback hook; instead, standard deployment hooks in the target revision will run.

Place the cleanup script in the correct lifecycle hook of the AppSpec file

The cleanup script is mapped to the BeforeInstall hook of the AppSpec file.

When the rollback deployment starts, the BeforeInstall hook runs before new files are copied, clearing out remnants of the failed deployment.

Key Concept

AWS CodeDeploy rollbacks are executed as new deployments of the last known successful revision, which run the standard AppSpec lifecycle hooks of that revision rather than a dedicated rollback hook.

Question 2Question →

A developer is managing an AWS CloudFormation stack for a production application. After a failed update to an Amazon RDS database instance, the stack is stuck in the UPDATE_ROLLBACK_FAILED state. The developer discovers that another team member had previously made manual, out-of-band configuration changes to the database instance directly in the AWS Console. How should the developer resolve this situation and successfully perform the stack update?

Manually delete the database instance via the Amazon RDS console, manually recreate a new database instance with the target configuration, and then run drift detection to automatically reconcile the stack.

Directly run the update-stack CLI command with the updated template and a --force-update flag to override the failed rollback state and apply the new configuration.

Identify the manual changes, use the CloudFormation console or CLI to run the ContinueUpdateRollback action to return the stack to a stable state, update the template to reflect the actual resource configuration, and then perform the update.

Create a new Systems Manager Parameter Store parameter of type String to store the database password, and update the template to reference it using the {{resolve:ssm:parameter_name}} dynamic reference.

Show answer & explanation

Answer: Identify the manual changes, use the CloudFormation console or CLI to run the ContinueUpdateRollback action to return the stack to a stable state, update the template to reflect the actual resource configuration, and then perform the update.

Answer

To resolve an UPDATE_ROLLBACK_FAILED state caused by out-of-band changes, the developer must run the ContinueUpdateRollback action to stabilize the stack, align the template with the actual resource state, and then perform the update.

Executing the ContinueUpdateRollback action is the standard AWS procedure to recover a stack from the UPDATE_ROLLBACK_FAILED state. Once the stack is stabilized to UPDATE_ROLLBACK_COMPLETE, the developer can align the template with the actual drifted state of the database and safely run the update.

Step-by-Step Solution

Identify manual configuration changes that caused the rollback failure.

Find the drift or discrepancy between the template and the actual resource state.

Manual out-of-band changes prevent CloudFormation from rolling back resources to their expected state.

Execute the ContinueUpdateRollback operation via the CLI or AWS Console.

The stack transitions from UPDATE_ROLLBACK_FAILED to UPDATE_ROLLBACK_COMPLETE.

This action bypasses or retries the failed rollback step, bringing the stack back to a stable state where updates are permitted.

Align the template with the actual configuration of the resources and redeploy.

The stack is successfully updated with no configuration drift.

Ensuring the template matches the real-world state prevents future update or rollback failures.

Key Concept

Resolving CloudFormation stack update rollback failures caused by resource drift

Estimated Time:1m 30s

Question 3Question →

A developer is setting up an AWS CodeBuild project to compile a Java application and upload the build artifacts to an Amazon S3 bucket. During the first build execution, CodeBuild fails to upload the artifacts, returning an Access Denied error. Additionally, the developer wants the project to use a custom build specification file named build-config.yml located in the config directory of the repository, rather than using the default root-level buildspec.yml file.

Which configuration steps must the developer perform to resolve the upload failure and use the custom build specification? (Select TWO.)

Select all that apply

Update the buildspec path in the CodeBuild project settings to config/build-config.yml.

Modify the CodeBuild service role permissions policy to allow the s3:PutObject action on the artifacts bucket.

Define the custom build specification contents within a Systems Manager Parameter Store parameter and pass the parameter name in the buildspec.

Create a default buildspec.yml file in the repository root and define a redirect block under the install phase pointing to config/build-config.yml.

Modify the IAM trust policy of the Amazon ECS task execution role to allow the codebuild.amazonaws.com service principal to assume it.

Show answer & explanation

Answer: Update the buildspec path in the CodeBuild project settings to config/build-config.yml.; Modify the CodeBuild service role permissions policy to allow the s3:PutObject action on the artifacts bucket.

Answer

The correct steps are to update the buildspec path in the CodeBuild project settings to point to the custom path, and to modify the CodeBuild service role permissions policy to allow writing objects to the S3 bucket.

To use a custom build specification file that is not in the root directory or has a different name, the developer must configure the file path in the project settings. Additionally, since the build environment failed to upload the artifacts to Amazon S3 with an Access Denied error, the CodeBuild service role must be updated with a policy that allows the write action on the target S3 bucket.

Step-by-Step Solution

Determine how CodeBuild locates a non-standard buildspec file name and path.

A custom buildspec path like config/build-config.yml must be configured directly within the CodeBuild project settings.

By default, CodeBuild expects buildspec.yml in the root directory. Any custom path or name must be specified in the project configuration.

Analyze the cause of the Access Denied error during artifact upload.

The CodeBuild build container runs under an IAM role (the service role). It requires explicit permissions to write objects to the S3 bucket where artifacts are stored.

Without s3:PutObject permissions attached to the CodeBuild service role, the upload will fail with an authorization error.

Key Concept

AWS CodeBuild custom buildspecs and permissions

Question 4Question →

A company is migrating a containerized web application to run on Amazon ECS using the Amazon EC2 launch type. Multiple instances of the application task must run on each container instance, and the tasks are configured to use the bridge network mode. The application code requires access to a database password stored in AWS Secrets Manager and must perform read operations on an Amazon DynamoDB table. Which two configurations are required to support this deployment?

Select all that apply

Set the container port to 80 and the host port to 0 (or leave it blank) in the task definition port mapping.

Configure the task definition's Task Role (taskRoleArn) with the IAM policies required to access the Amazon DynamoDB table and AWS Secrets Manager.

Configure the task definition's Task Execution Role (executionRoleArn) with the IAM policies required to access the Amazon DynamoDB table and AWS Secrets Manager.

Configure the IAM role for application permissions with a trust policy that allows the ec2.amazonaws.com service principal to assume the role.

Store the database password as a plaintext environment variable directly in the container definition of the ECS task definition.

Show answer & explanation

Answer: Set the container port to 80 and the host port to 0 (or leave it blank) in the task definition port mapping.; Configure the task definition's Task Role (taskRoleArn) with the IAM policies required to access the Amazon DynamoDB table and AWS Secrets Manager.

Answer

Configure dynamic port mapping by setting the host port to 0 or leaving it blank, and assign the required IAM policies to the ECS Task Role (taskRoleArn) with a trust policy for ecs-tasks.amazonaws.com.

To support running multiple instances of the container on a single EC2 host using the bridge network mode, dynamic host port mapping is required. This is achieved by setting the host port to 0 or leaving it blank in the task definition port mapping, which allows the ECS agent to automatically map the container port to a random ephemeral port on the host. Furthermore, the application container requires AWS credentials at runtime to query the DynamoDB table and fetch secrets from Secrets Manager. These application-level permissions must be defined in an IAM role assigned to the taskRoleArn (Task Role) parameter of the task definition.

Step-by-Step Solution

Configure the port mapping in the task definition for bridge network mode with the host port set to 0 or left blank.

Enables dynamic port mapping, letting the ECS agent bind the container's port to a random host port.

Allows multiple task instances to run on the same EC2 instance without port conflicts.

Create an IAM role that trusts the ecs-tasks.amazonaws.com service principal and attach permission policies for DynamoDB and Secrets Manager.

Creates a role that ECS tasks can assume to perform API operations on AWS services.

Secures application credentials by avoiding hardcoded values and granting access via temporary credentials.

Assign this role to the taskRoleArn parameter in the ECS task definition.

Ensures the containerized application executes with the permissions defined in the IAM role.

Maintains the separation of concerns by assigning application access to the Task Role rather than the Task Execution Role.

Key Concept

ECS Task Role vs Task Execution Role and Bridge Network Mode Port Mapping

Estimated Time:2m 0s

Question 5Question →

A developer is setting up an AWS CodeBuild project to build a containerized application. The build process needs to retrieve a database password securely from AWS Secrets Manager. The developer has stored a custom build specification file at the path `build/pipelines/buildspec-dev.yml` in the source repository. During the initial build run, CodeBuild fails immediately because it cannot locate the build specification, and the database credentials are not resolved. Which two actions should the developer take to configure the project correctly? (Choose two.)

Select all that apply

Update the CodeBuild project configuration to set the buildspec file path to build/pipelines/buildspec-dev.yml

In the buildspec-dev.yml file, retrieve the database password by defining it under the secrets-manager key in the env section

In the buildspec-dev.yml file, retrieve the database password by defining it under the parameter-store key in the env section

Modify the IAM trust policy of the CodeBuild service role to allow the Systems Manager service (ssm.amazonaws.com) to assume the role

Add a shell command in the install phase of the buildspec file to copy the buildspec-dev.yml file to the root of the source directory

Show answer & explanation

Answer: Update the CodeBuild project configuration to set the buildspec file path to build/pipelines/buildspec-dev.yml; In the buildspec-dev.yml file, retrieve the database password by defining it under the secrets-manager key in the env section

Answer

To configure the project correctly, the developer must update the CodeBuild project settings to set the buildspec path to the custom subdirectory path, and update the buildspec-dev.yml file to declare the secret under the secrets-manager key in the env section.

To resolve the buildspec locator issue, the developer must explicitly configure the custom file path in the CodeBuild project configuration since it is not named buildspec.yml at the root. To retrieve the secret correctly, the developer must define it under the secrets-manager key in the env block, which instructs CodeBuild to retrieve the value from Secrets Manager natively.

Step-by-Step Solution

Configure the CodeBuild project settings to point to the correct buildspec location.

CodeBuild is successfully able to locate and parse the buildspec file from build/pipelines/buildspec-dev.yml instead of failing at the start of the build.

By default, CodeBuild only searches for buildspec.yml at the root directory of the source provider. Any other name or path must be configured in the project settings.

Configure the env section of the buildspec-dev.yml file to pull the database password from Secrets Manager.

The database password is dynamically retrieved and exposed as an environment variable in the build environment.

Using the native secrets-manager key in the env block tells CodeBuild to fetch the secret from AWS Secrets Manager using the service role's permissions.

Key Concept

AWS CodeBuild buildspec configuration and Secrets Manager integration

Question 6Question →

A developer is setting up an AWS CodeDeploy deployment group for an in-place deployment of a web application to a fleet of Amazon EC2 instances. The deployment fails during the DownloadBundle phase because the CodeDeploy agent on the EC2 instances cannot access the deployment bundle in the Amazon S3 bucket. Additionally, the developer needs to store database credentials securely and retrieve them during the deployment process rather than packaging them in the deployment bundle.

Which two actions should the developer take to resolve these issues? (Select TWO.)

Select all that apply

Attach an IAM policy to the EC2 instance profile role that allows the s3:GetObject action on the S3 bucket containing the deployment bundle.

Store the database credentials as SecureString parameters in AWS Systems Manager Parameter Store, and write a script in the AppSpec BeforeInstall hook to retrieve them.

Attach an IAM policy to the CodeDeploy service role that allows the s3:GetObject action on the S3 bucket containing the deployment bundle.

Configure the trust policy of the CodeDeploy service role to allow the ec2.amazonaws.com service to assume the role.

Store the database credentials as plaintext parameters in AWS Systems Manager Parameter Store, and write a script in the AppSpec AfterAllowTraffic hook to retrieve them.

Show answer & explanation

Answer: Attach an IAM policy to the EC2 instance profile role that allows the s3:GetObject action on the S3 bucket containing the deployment bundle.; Store the database credentials as SecureString parameters in AWS Systems Manager Parameter Store, and write a script in the AppSpec BeforeInstall hook to retrieve them.

Answer

Attach an IAM policy to the EC2 instance profile role that allows the s3:GetObject action on the S3 bucket containing the deployment bundle, and store the database credentials as SecureString parameters in AWS Systems Manager Parameter Store, retrieving them in the AppSpec BeforeInstall hook.

The correct options involve configuring the EC2 instance profile role with the appropriate S3 read permissions so the CodeDeploy agent can download the bundle, and securely storing credentials in Systems Manager Parameter Store as SecureString parameters, retrieving them during a valid EC2 lifecycle hook like BeforeInstall.

Step-by-Step Solution

Analyze the cause of the CodeDeploy agent S3 access failure.

The agent runs on the EC2 instances and uses the instance profile role to download the deployment bundle. S3 permissions must be granted to the instance profile role, not the CodeDeploy service role.

Permissions must align with the identity executing the action, which is the CodeDeploy agent on EC2.

Determine the secure method and correct lifecycle hook for credential retrieval on EC2.

Store credentials as SecureString parameters in AWS Systems Manager Parameter Store and retrieve them using a lifecycle hook valid for EC2, such as BeforeInstall.

This avoids plaintext storage and uses a hook that is compatible with EC2 in-place deployments.

Key Concept

AWS CodeDeploy permissions and AppSpec configuration on EC2

Question 7Question →

A developer is configuring an AWS CloudFormation template to deploy an application that requires a database password. The password must be stored securely and rotated automatically every 30 days. Additionally, the developer must ensure that if a stack update fails, the resources are reverted to their previous working state. Which CloudFormation configurations and features should the developer use to meet these requirements? (Select TWO.)

Select all that apply

Use a CloudFormation dynamic reference to retrieve the database password from AWS Secrets Manager.

Allow the default CloudFormation behavior to roll back the stack automatically to its last stable state if the update fails.

Use a Systems Manager Parameter Store dynamic reference to retrieve the password, and configure Parameter Store to rotate the secret every 30 days.

Change the password manually using the Amazon RDS console, then execute a CloudFormation drift detection operation to update the stack's template parameters.

Disable the stack's rollback-on-failure setting and execute the AWS CLI command to manually reconcile and clean up the database state.

Show answer & explanation

Answer: Use a CloudFormation dynamic reference to retrieve the database password from AWS Secrets Manager.; Allow the default CloudFormation behavior to roll back the stack automatically to its last stable state if the update fails.

Answer

To securely reference a rotating password and ensure automatic rollback on failure, the developer should use a dynamic reference to retrieve the database password from AWS Secrets Manager and allow CloudFormation to execute its default automatic rollback behavior.

To retrieve a secret that rotates automatically, using a dynamic reference to AWS Secrets Manager is the correct choice because Secrets Manager natively handles automatic secret rotation. Allowing the default CloudFormation rollback behavior ensures that any failed updates are automatically reverted to the last stable configuration without manual intervention.

Step-by-Step Solution

Select a secure storage service for the database password that supports rotation.

Identify AWS Secrets Manager as the appropriate service because it supports automatic rotation, unlike Systems Manager Parameter Store.

The requirements demand a secure password storage solution that rotates every 30 days.

Integrate the secure storage with the CloudFormation template.

Configure a dynamic reference in the template to fetch the password from AWS Secrets Manager at deployment time.

Dynamic references retrieve sensitive values from external systems without exposing them in plaintext inside the template.

Evaluate the rollback strategy for failed updates.

Ensure default automatic rollback is enabled for the stack.

CloudFormation's default behavior is to roll back to the last stable state automatically when an update fails, satisfying the requirement to revert changes.

Key Concept

AWS CloudFormation manages resources declaratively. Using dynamic references to AWS Secrets Manager handles rotating credentials securely, while default stack rollback behavior ensures automated state recovery from update failures.

Estimated Time:1m 0s

Question 8Question →

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 9Question →

A developer manages a production application stack deployed via AWS CloudFormation. The stack consists of an Amazon RDS DB instance and an Auto Scaling group of Amazon EC2 instances. During a recent deployment, a stack update failed while attempting to modify the DB instance parameters, and the subsequent automatic rollback also failed, leaving the stack in the UPDATE_ROLLBACK_FAILED state. The developer needs to update the launch template of the Auto Scaling group to apply a critical security patch immediately without deleting the existing stack or losing DB instance data. How can the developer successfully apply the launch template update to the stack?

Run the `continue-update-rollback` command and specify the RDS DB instance in the resources to skip parameter. Once the stack status transitions to `UPDATE_ROLLBACK_COMPLETE`, perform the stack update with the modified Auto Scaling group configuration.

Initiate a new stack update using the `update-stack` command with the `--force` flag to bypass the failed rollback state and overwrite the Auto Scaling group configurations.

Execute the `rollback-stack` command to manually force the stack to return to the last known stable state of `CREATE_COMPLETE`, and then run the update command for the Auto Scaling group.

Perform drift detection on the stack to identify the mismatched RDS configuration, then execute the `resolve-drift` command to automatically align the stack state and reset the status to `UPDATE_ROLLBACK_COMPLETE`.

Show answer & explanation

Answer: Run the `continue-update-rollback` command and specify the RDS DB instance in the resources to skip parameter. Once the stack status transitions to `UPDATE_ROLLBACK_COMPLETE`, perform the stack update with the modified Auto Scaling group configuration.

Answer

The correct answer is to run the `continue-update-rollback` command and specify the RDS DB instance in the resources to skip parameter. When a CloudFormation stack update fails and the rollback also fails, the stack enters the `UPDATE_ROLLBACK_FAILED` state. To perform further updates, the developer must get the stack into a stable state. By continuing the update rollback and skipping the failing DB instance resource, CloudFormation can successfully roll back the rest of the stack, transitioning it to the `UPDATE_ROLLBACK_COMPLETE` state. Once in this stable state, the developer can initiate the stack update for the Auto Scaling group.

Step-by-Step Solution

Identify the resource causing the rollback failure (the Amazon RDS DB instance) and execute the `continue-update-rollback` command (or use the console equivalent).

The stack bypasses the failed rollback of the DB instance and rolls back the other resources successfully.

This is necessary because a stack in the `UPDATE_ROLLBACK_FAILED` state cannot be updated directly; it must first reach a stable state.

Wait for the stack status to transition from `UPDATE_ROLLBACK_FAILED` to `UPDATE_ROLLBACK_COMPLETE`.

The stack enters a stable, updatable state.

CloudFormation only allows stack updates when the stack is in a stable status such as `UPDATE_ROLLBACK_COMPLETE` or `CREATE_COMPLETE`.

Perform the stack update using the template containing the modified launch template configuration for the Auto Scaling group.

The Auto Scaling group is updated successfully with the critical security patch.

This applies the required changes to the Auto Scaling group now that the stack is in an updatable state.

Key Concept

Handling CloudFormation stack updates and failures by using the ContinueUpdateRollback action to skip failing resources and return the stack to a stable state.

Question 10Question →

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 11Question →

A developer is planning the deployment strategy for a critical web application hosted on AWS Elastic Beanstalk. The application is highly sensitive to performance degradation, so the deployment process must maintain $100\%$ of the existing instance capacity at all times. Additionally, if the new version fails post-deployment tests, the developer must be able to roll back to the previous version almost instantly. Which two Elastic Beanstalk deployment strategies or methods will satisfy these requirements? (Select two.)

Select all that apply

Immutable deployment

Blue/Green deployment via environment URL swap

Rolling deployment

Rolling with additional batch deployment

All-at-once deployment

Show answer & explanation

Answer: Immutable deployment; Blue/Green deployment via environment URL swap

Answer

Immutable deployment and Blue/Green deployment via environment URL swap

Immutable deployments and Blue/Green deployments via environment URL swapping both maintain

100\%

of the existing application capacity during deployment. They also provide a rapid rollback path: immutable deployments roll back by terminating the new Auto Scaling group, while Blue/Green deployments roll back by swapping the CNAME records back.

Step-by-Step Solution

Analyze the capacity requirement.

The application must maintain

100\%

of its existing capacity during the deployment. This eliminates strategies that take instances offline without replacing them first, such as rolling and all-at-once.

To prevent performance degradation during the deployment window.

Evaluate the rollback requirements.

The deployment must support a rapid, near-instant rollback in case of failure. This rules out rolling with additional batch, which requires a new rolling deployment of the older version to revert.

To minimize the duration of any potential outage or failure.

Identify the compliant strategies.

Immutable deployments maintain capacity by launching a parallel Auto Scaling group and roll back instantly by terminating it. Blue/Green deployments maintain capacity in a separate environment and roll back instantly by swapping the CNAMEs back.

Both strategies meet the full capacity and near-instant rollback constraints.

Key Concept

Evaluating Elastic Beanstalk deployment policies based on capacity and rollback speed trade-offs.

Estimated Time:1m 30s

Question 12Question →

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 13Question →

A developer is preparing a source bundle to deploy a web application to AWS Elastic Beanstalk. The developer wants to include configuration files that install additional software packages and define system environment variables. In which directory must these configuration files be placed to ensure Elastic Beanstalk processes them during deployment?

A folder named ebextensions without a leading dot at the root level of the application source bundle

A folder named .elasticbeanstalk at the root level of the application source bundle

A folder named .ebextensions at the root level of the application source bundle

A folder named .ebextensions nested inside the primary source code directory, such as src/

Show answer & explanation

Answer: A folder named .ebextensions at the root level of the application source bundle

Answer

A folder named .ebextensions at the root level of the application source bundle

The correct answer specifies placing files in a directory named .ebextensions at the root level of the application source bundle. AWS Elastic Beanstalk automatically looks for configuration files with a .config extension inside this directory during deployment to customize the environment's resource configuration.

Step-by-Step Solution

Identify the mechanism Elastic Beanstalk uses for custom configuration files.

Elastic Beanstalk relies on YAML or JSON configuration files (ending in .config) to configure the environment.

This allows developers to define packages, services, files, and commands to run on the EC2 instances.

Determine the required naming convention and location for these files.

The configuration files must be stored within a directory named .ebextensions, which must be located at the root of the application source bundle.

Elastic Beanstalk only parses configuration files that are situated in this specific root folder.

Key Concept

AWS Elastic Beanstalk Custom Configurations (.ebextensions)

Question 14Question →

A developer is configuring a deployment template for a new serverless application using the AWS Serverless Application Model (SAM). The template contains the following partial structure:

yaml
Transform: AWS::Serverless-2016-10-31
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs18.x
CodeUri: ./src

Which two steps or configurations are required to successfully deploy and run this serverless application? (Select two.)

Select all that apply

The template must declare the Transform header at the root level of the template file to instruct CloudFormation on how to process SAM-specific resources.

The local function code located in the './src' directory must be packaged and uploaded to an Amazon S3 bucket prior to deploying the CloudFormation stack.

The template must list the Lambda function resource under the Globals section instead of the Resources section.

The API Gateway event source must be configured with a custom integration rather than a proxy integration to allow SAM to automatically map HTTP header values.

The Lambda function's IAM trust policy must explicitly grant permissions to retrieve runtime configuration secrets from AWS Secrets Manager.

Show answer & explanation

Answer: The template must declare the Transform header at the root level of the template file to instruct CloudFormation on how to process SAM-specific resources.; The local function code located in the './src' directory must be packaged and uploaded to an Amazon S3 bucket prior to deploying the CloudFormation stack.

Answer

The configurations required are: (1) declaring the Transform header at the root level of the template file, and (2) packaging and uploading the local function code in the './src' directory to an Amazon S3 bucket.

The correct answer states that the Transform declaration must be at the root of the template file to instruct CloudFormation how to parse the SAM shorthand syntax, and that local function artifacts in the source directory must be zipped and uploaded to an S3 bucket prior to CloudFormation execution.

Step-by-Step Solution

Analyze template syntax and transformation requirement.

Identify that the 'Transform: AWS::Serverless-2016-10-31' line is required at the root of the template.

This header informs AWS CloudFormation that it must parse the template using the Serverless transform to expand SAM resources into standard CloudFormation resources.

Analyze code deployment requirements.

Confirm that local files specified by 'CodeUri: ./src' must be packaged.

CloudFormation requires function code to be hosted in an Amazon S3 bucket. The packaging phase zips the local code directory, uploads it, and replaces the local path with the S3 URI.

Key Concept

AWS SAM templates require a root-level transform declaration to be parsed by AWS CloudFormation, and local deployment artifacts must be packaged and uploaded to S3.

Estimated Time:1m 0s

Question 15Question →

A developer is managing an application stack using AWS CloudFormation. The stack contains an Amazon RDS DB instance and an Amazon EC2 instance within an Amazon VPC. The developer has two new requirements:

1. Securely store the database credentials and ensure they are rotated automatically every $30$ days.
2. Detect any manual configuration changes made directly to the EC2 security group and restore the security group to the state defined in the CloudFormation template.

Which combination of actions should the developer take to meet these requirements? (Select TWO.)

Select all that apply

Store the database credentials in AWS Secrets Manager, configure automatic rotation, and reference the secret in the CloudFormation template using a dynamic reference.

Perform drift detection on the CloudFormation stack, review the drifted resources, and manually edit the security group in the Amazon VPC console to match the template configuration.

Store the database credentials in AWS Systems Manager Parameter Store as a SecureString parameter, configure the built-in Parameter Store rotation schedule, and reference it in the template using a dynamic reference.

Use the CloudFormation console to run drift detection, select the drifted security group, and click the Reconcile Drift button to automatically overwrite the live resource configurations with the template state.

Initiate a stack update using a modified template to trigger a rollback, then use the ContinueUpdateRollback API while the stack is in the ROLLBACK_IN_PROGRESS state to force the security group back to its original state.

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager, configure automatic rotation, and reference the secret in the CloudFormation template using a dynamic reference.; Perform drift detection on the CloudFormation stack, review the drifted resources, and manually edit the security group in the Amazon VPC console to match the template configuration.

Answer

Store the database credentials in AWS Secrets Manager with automatic rotation, reference it via dynamic references, perform drift detection, and manually revert the out-of-band security group changes.

The correct combination is to store the credentials in AWS Secrets Manager and use dynamic references, which supports the

30

-day rotation requirement, and to use drift detection to identify out-of-band changes, followed by manual remediation to revert the security group to the configuration defined in the template.

Step-by-Step Solution

Evaluate the database credential rotation requirement.

AWS Secrets Manager is the correct service because it natively supports secret rotation (such as RDS credentials) every

30

days, whereas Parameter Store does not have built-in rotation.

Choosing the correct secrets management service ensures security compliance and automatic rotation requirements are met.

Address the dynamic reference requirement in the CloudFormation template.

Use dynamic references to retrieve the secret securely without hardcoding parameters.

Dynamic references allow CloudFormation to pull secrets securely from Secrets Manager during stack creation or updates.

Evaluate how to detect and remediate out-of-band changes (drift) in CloudFormation.

Run drift detection on the stack to identify which resources differ from the template. Because CloudFormation does not have an automatic one-click remediation feature, manually modify the resource (security group) back to the template specifications.

This identifies the exact drift and brings the resource back to the desired configuration manually, correcting the out-of-band change.

Key Concept

AWS CloudFormation Drift Detection and secrets management integration

Question 16Question →

A developer is attempting to deploy a serverless application using a template file named template.yaml. The file contains the following code:

yaml
Resources:
ProcessOrderFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs18.x
CodeUri: ./src
Events:
PostOrder:
Type: Api
Properties:
Path: /orders
Method: post

When deploying this template directly via AWS CloudFormation, the deployment fails with the error message: `Template format error: Unrecognized resource type: AWS::Serverless::Function`.

Which of the following additions to the template will resolve this error?

Add `Transform: AWS::Serverless-2016-10-31` at the root level of the template.

Add an IAM trust policy that explicitly allows the `apigateway.amazonaws.com` service to assume the execution role of the Lambda function.

Specify the `Integration: AWS_PROXY` property under the `Events` section of the serverless function.

Configure a `Timeout` property under `Globals` to match the execution environment's maximum execution duration.

Show answer & explanation

Answer: Add `Transform: AWS::Serverless-2016-10-31` at the root level of the template.

Answer

To resolve the unrecognized resource type error, the `Transform: AWS::Serverless-2016-10-31` declaration must be added at the root level of the template. This declaration tells AWS CloudFormation to process the template using the AWS SAM translator, which converts serverless-specific resources like `AWS::Serverless::Function` into standard AWS CloudFormation resources.

The template contains an `AWS::Serverless::Function` resource, which is a custom resource type extension provided by the AWS Serverless Application Model (SAM). AWS CloudFormation does not natively recognize this resource type. To enable CloudFormation to parse and translate this template into standard resources, the `Transform: AWS::Serverless-2016-10-31` line must be included at the root level of the template. Adding this declaration resolves the parsing error.

Step-by-Step Solution

Analyze the error message returned during template deployment.

The error indicates that the resource type `AWS::Serverless::Function` is unrecognized by AWS CloudFormation.

This tells us that the parser is treating the template as standard CloudFormation and does not know how to translate SAM resources.

Check the root level of the template for the required transform declaration.

The template only has a `Resources` block and is missing the `Transform` declaration.

AWS CloudFormation requires a macro to process the SAM template format into standard CloudFormation resources.

Add the transform statement to the template.

Inserting `Transform: AWS::Serverless-2016-10-31` at the root allows CloudFormation to parse the SAM resources.

This macro transforms the serverless resource declarations into their underlying AWS CloudFormation resources (like `AWS::Lambda::Function` and `AWS::IAM::Role`) during deployment.

Key Concept

AWS SAM templates extend AWS CloudFormation. To deploy SAM resources using CloudFormation, the template must include the `Transform: AWS::Serverless-2016-10-31` declaration. This triggers the CloudFormation transform macro to parse and compile SAM-specific resources into standard CloudFormation resources.

Question 17Question →

An operations team manages a production application infrastructure stack deployed via AWS CloudFormation. The stack consists of an Amazon ECS service, an Application Load Balancer (ALB), and an Amazon DynamoDB table. During a previous template update, a resource configuration error caused a failure, leaving the stack stuck in the `UPDATE_ROLLBACK_FAILED` state. Additionally, a drift detection scan indicates that another team member manually modified the ALB's security group out-of-band to allow traffic from a new partner IP range. The team must successfully deploy the new application updates while preserving the manual security group modifications. Which combination of actions should the team take to meet these requirements? (Select TWO.)

Select all that apply

Run the `continue-update-rollback` command on the stack to return it to the `UPDATE_ROLLBACK_COMPLETE` state.

Update the CloudFormation template definition for the security group to match the manually allowed IP ranges before initiating the next stack update.

Execute the `update-stack` command directly with the `--rollback-configuration` parameter to override the failed state and apply the new template.

Run the `resolve-drift` command to automatically synchronize the template definition with the live security group configurations.

Delete the stack and deploy it again, as CloudFormation will automatically detect the drifted security group during recreation and import its manual settings.

Show answer & explanation

Answer: Run the `continue-update-rollback` command on the stack to return it to the `UPDATE_ROLLBACK_COMPLETE` state.; Update the CloudFormation template definition for the security group to match the manually allowed IP ranges before initiating the next stack update.

Answer

To resolve this issue, the team must run the `continue-update-rollback` command on the stack to return it to the `UPDATE_ROLLBACK_COMPLETE` state, and update the CloudFormation template definition for the security group to match the manually allowed IP ranges before initiating the next stack update.

To successfully deploy new updates while preserving the manual security group configurations, the team must first stabilize the stack by running `continue-update-rollback`, which moves it from `UPDATE_ROLLBACK_FAILED` to `UPDATE_ROLLBACK_COMPLETE`. Secondly, they must update the template code to match the manually added IP range rules. This reconciles the drift and prevents CloudFormation from overwriting the manual changes during the subsequent update.

Step-by-Step Solution

Address the failed rollback state

The stack transitions to the `UPDATE_ROLLBACK_COMPLETE` state.

CloudFormation stacks in the `UPDATE_ROLLBACK_FAILED` state do not accept updates. Running `continue-update-rollback` retries or bypasses the failed rollback actions to bring the stack back to a stable state.

Reconcile the configuration drift

The template definition is aligned with the live configuration of the security group.

Since the security group has been manually modified out-of-band, the template code must be updated to match these live settings. Otherwise, the next stack update would overwrite these manual rules or fail due to drift.

Perform the stack update

The stack is updated with the new template changes without losing the security group rules.

Once the stack is in a stable state and the template has been updated to reflect the drift, the stack update can proceed safely.

Key Concept

CloudFormation Stack Recovery and Drift Reconciliation

Question 18Question →

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 19Question →

An organization is deploying a Node.js web application to a single-instance environment on AWS Elastic Beanstalk. The application must store local application log files in a custom directory on the host Amazon EC2 instance. Additionally, the application needs to retrieve database credentials dynamically at runtime from AWS Systems Manager Parameter Store.

Which two actions must a developer take to meet these requirements?

Select all that apply

Create a directory named `.ebextensions` at the root of the application source bundle, and place a configuration file inside it to create the custom log directory.

Create a directory named `ebextensions` (without the leading dot) at the root of the application source bundle, and place a configuration file inside it to create the custom log directory.

Attach an IAM policy with `ssm:GetParameters` permissions to the IAM role associated with the Elastic Beanstalk EC2 instance profile, and retrieve the parameters using the application code.

Attach an IAM policy with `ssm:GetParameters` permissions to the Elastic Beanstalk service role (`aws-elasticbeanstalk-service-role`).

Hardcode a temporary set of AWS access keys with access to AWS Systems Manager in the application source code configuration.

Show answer & explanation

Answer: Create a directory named `.ebextensions` at the root of the application source bundle, and place a configuration file inside it to create the custom log directory.; Attach an IAM policy with `ssm:GetParameters` permissions to the IAM role associated with the Elastic Beanstalk EC2 instance profile, and retrieve the parameters using the application code.

Answer

Create a directory named `.ebextensions` at the root of the application source bundle to place the configuration file, and attach an IAM policy with `ssm:GetParameters` permissions to the IAM role associated with the EC2 instance profile.

The correct options are creating the `.ebextensions` directory at the root to contain the configuration file, and granting Systems Manager permissions to the EC2 instance profile role. The `.ebextensions` directory is the standard location for environment customization files, and the EC2 instance profile role provides permissions to the application code running on the EC2 instances.

Step-by-Step Solution

Configure instance initialization using Beanstalk configuration files.

Create a directory named `.ebextensions` at the root of the source bundle and place configuration files (e.g., `.config`) inside it.

Elastic Beanstalk platform engine detects and processes configuration files only when they are placed in a folder named `.ebextensions` with a leading dot at the root level of the application zip archive.

Establish secure permissions for Parameter Store access.

Add `ssm:GetParameters` permissions to the EC2 instance profile role used by the environment.

Since the application code running on the EC2 instances needs to call the Systems Manager API, the instance profile role provides the necessary temporary credentials via the EC2 Instance Metadata Service.

Key Concept

AWS Elastic Beanstalk environment customization and application permissions using instance profiles.

Question 20Question →

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.

Page 1 / 19Next

Deployment

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