Task 1.1: Implement CI/CD pipelines.

• ACreate a customer managed KMS key in the pipeline's Region that the production account may use, make it the artifact store key, and grant the production role access to the bucket

  Correct

  This is the documented setup for cross-account actions: a customer managed key in the pipeline Region that the other account may use, the pipeline edited to use that key, and a bucket policy that gives the other account access to the artifact bucket.

• BKeep the default AWS managed key and add a bucket policy statement that grants the production account's deploy role s3:GetObject on every object in the artifact bucket

  Incorrect

  The default AWS managed key cannot be changed, so the production account still could not decrypt the artifacts. Cross-account actions need a customer managed key that grants the other account.

• CRemove default encryption from the artifact bucket and add a bucket policy that denies every request that does not use TLS

  Incorrect

  This drops encryption at rest with AWS KMS, which the security team requires. Requiring TLS protects data in transit only.

• DCreate a customer managed KMS key in the production account and reference it by its alias in the pipeline's artifact store settings

  Incorrect

  An alias is recognized only in the account that created the key. For cross-account actions the key must be given by key ID or key ARN, and the documented setup creates the key in the pipeline's account and Region.

A cross-account action reads artifacts that the pipeline account wrote, so the other account needs both the bucket and the key. Only a customer managed key can grant another account; then the pipeline is switched to that key and the bucket policy and the assumed role give the access.

• AStore the token as a SecureString parameter in Parameter Store and map it under env/parameter-store in the buildspec

  Incorrect

  This hides the value, but Parameter Store has no credential rotation. AWS recommends Secrets Manager for tokens because it adds automatic rotation.

• BKeep the environment variable in the project and encrypt the project's build output with a customer managed KMS key

  Incorrect

  Plaintext environment variables can still be displayed in the CodeBuild console and the AWS CLI, which is what the auditors found, and nothing rotates the token.

• CStore the token in AWS Secrets Manager with a rotation schedule that uses the vendor's function, and map it under env/secrets-manager in the buildspec

  Correct

  CodeBuild resolves env/secrets-manager references when the build runs, so each build gets the current value, and Secrets Manager rotates secrets of other types with a Lambda function on a schedule.

• DCommit the token to the repository encrypted with a KMS key, decrypt it with the AWS CLI in the pre_build phase, and commit a new file after each rotation

  Incorrect

  Nothing would rotate the copy in the repository, so builds would use a stale token after rotation. Automatic rotation is a Secrets Manager feature.

The buildspec can pull values from Parameter Store or Secrets Manager instead of holding them in plaintext. Only Secrets Manager rotates credentials, and its rotation by Lambda function covers secrets such as third-party tokens. The CodeBuild service role also needs permission to read the secret.

• AAdd a first CodeBuild action to each pipeline that runs git diff and stops the execution when the service folder did not change

  Incorrect

  All 12 pipelines would still start on every push, and the team would maintain the diff scripts. Pipeline triggers can filter on file paths without custom code.

• BSet each pipeline's execution mode to QUEUED so that pushes to main are processed one at a time in order

  Incorrect

  Execution modes decide how executions that have already started are processed. They do not decide which pushes start a pipeline.

• CUse type V2 pipelines with a push trigger that filters on the main branch and on the file path of each service's folder

  Correct

  V2 pipelines add trigger configuration, and push triggers can filter on branches and file paths, so each pipeline starts only for its own folder.

• DGive each service its own long-lived branch and point each pipeline's source action at the branch of its service

  Incorrect

  This changes how developers work and moves changes off main, which the requirement keeps. Trigger filters handle folders on one branch.

Trigger filters on V2 pipelines start an execution only for the Git events that match, such as pushes to a given branch that change files under a given path. That keeps a monorepo on one branch while each pipeline reacts only to its own folder.

• ATurn on S3 Cross-Region Replication from the us-east-1 artifact bucket to a bucket in eu-west-1

  Incorrect

  CodePipeline itself uses a separate artifact bucket in the action's Region, named in artifactStores. Bucket replication is not part of the setup.

• BReplace artifactStore with an artifactStores map that names an S3 bucket and a KMS key for us-east-1 and for eu-west-1

  Correct

  A pipeline with cross-region actions needs an artifact bucket in its own Region and one in each Region where an action runs, listed in the artifactStores map with their encryption keys.

• CSet the region field of the new CloudFormation action in the deploy stage to eu-west-1

  Correct

  A cross-region action is declared by adding the optional region field to the action in the pipeline structure.

• DCreate the eu-west-1 artifact bucket and KMS key in the account that will host the eu-west-1 stack

  Incorrect

  The artifact bucket and key for a cross-region action must be in the action's Region and in the same account as the pipeline.

• ECreate a second pipeline in eu-west-1 that an Amazon EventBridge rule starts when the us-east-1 pipeline succeeds

  Incorrect

  That is a second pipeline, not the same pipeline, and it would run after instead of in parallel. CodePipeline supports actions in other Regions directly.

For cross-region actions, the pipeline keeps one artifact store per Region in its own account. When the pipeline is defined with CloudFormation, the CLI or an SDK, you provide those buckets and keys yourself; the console creates default buckets for you.

• ASet the pipeline's execution mode to PARALLEL so that no execution has to wait for another one to finish

  Incorrect

  In PARALLEL mode executions run at the same time and independently, so they are neither one at a time nor guaranteed to finish in merge order.

• BKeep the current mode and add a manual approval action before the stage that runs the migrations

  Incorrect

  The default mode is SUPERSEDED, in which a more recent execution can overtake an older one, so an approval gate does not stop changes from being skipped.

• CUse a type V2 pipeline and set its execution mode to QUEUED so that later executions wait for earlier ones

  Correct

  In QUEUED mode executions are processed one by one in the order they are queued. This mode requires pipeline type V2.

• DSplit the stages into separate pipelines that start each other through Amazon EventBridge rules

  Incorrect

  Each new pipeline would still use the default SUPERSEDED mode, so newer executions could overtake older ones, and the chain is harder to run.

CodePipeline offers three execution modes. SUPERSEDED, the default, lets a newer execution replace an older one; QUEUED runs executions one at a time in order; PARALLEL runs them independently. QUEUED and PARALLEL need a V2 pipeline.

• ARevert the commit in the repository and let the pipeline build and deploy the previous code again

  Incorrect

  This rebuilds from source, which the team wants to avoid, and takes the full pipeline time.

• BRoll back the Prod stage to its last successful execution and that execution's revisions

  Correct

  Stage rollback reuses the source revisions and variables of the chosen successful execution and shows as a rollback execution.

• CDisable the transition into the Prod stage so that the failed release is removed from production

  Incorrect

  Disabling a transition stops new runs from entering the stage; it does not undo what is already deployed.

• DSwitch the pipeline to PARALLEL mode so that the previous release runs next to the new one

  Incorrect

  PARALLEL mode runs executions independently, and stage rollback is not available in that mode.

CodePipeline can roll back a stage to an execution that succeeded in that stage. The rollback is a new execution based on the target execution's revisions.

• AA FILE_PATH filter that excludes changes to the buildspec file from triggering builds

  Incorrect

  Other files can still change what the build runs, and unknown contributors would still trigger builds.

• BA COMMIT_MESSAGE filter that requires the text [run-tests] in every commit that should start a build

  Incorrect

  Anyone can write that text into a commit message.

• CA BASE_REF filter so that only pull requests into the main branch start a build

  Incorrect

  Pull requests from anyone can target main.

• DA webhook filter group with an ACTOR_ACCOUNT_ID filter for the team members' GitHub IDs

  Correct

  ACTOR_ACCOUNT_ID matches the account ID of the sender of the webhook event, so builds start only for those accounts.

Webhook filter groups trigger a build only when all filters in a group match. ACTOR_ACCOUNT_ID restricts builds to events sent by specific GitHub accounts.

• ASet timeoutInMinutes on this approval action to 72,000 (50 days) in the pipeline definition

  Correct

  The approval timeout can be overridden per action up to 86,400 minutes (60 days), so this one action waits through the longest board cycle and no other action's timeout changes.

• BReplace the approval with a Step Functions invoke action whose Standard workflow waits for the board with a callback task token

  Incorrect

  A task token can wait for a person for up to a year, but the pipeline's Step Functions action fails after 7 days by default, and raising that quota changes the timeout for all such actions in the account.

• CDisable the inbound transition into the Prod stage and enable it again after the board approves the release

  Incorrect

  This holds a release between stages for up to 30 days. After a longer wait, the execution does not resume unless a new change arrives or the pipeline is rerun, which rebuilds the release.

• DStart the pipeline from an EventBridge schedule two days before each board meeting so that the approval waits only briefly

  Incorrect

  A scheduled start begins a new execution at the source stage, so the release is built again instead of the one the board reviewed, and a fixed schedule does not fit meetings 35 to 45 days apart.

The manual approval action has an account-level default timeout of seven days, which a single action can override with timeoutInMinutes from 5 to 86,400 minutes. Disabled transitions are limited to 30 days, and the pipeline's Step Functions action has its own seven-day default timeout.

• APARALLEL mode, so that executions run simultaneously and independently of one another

  Correct

  In PARALLEL mode executions do not wait for other runs; stage rollback is not available, which the team does not use.

• BSUPERSEDED mode, so that newer executions overtake older ones as they move through stages

  Incorrect

  Superseding replaces older executions, which is what developers complain about.

• CQUEUED mode, so that executions are processed one by one in the order in which they started

  Incorrect

  Queued executions wait for each other.

• DSUPERSEDED mode with a manual approval at the start of each stage to keep the branches apart

  Incorrect

  Approvals add waiting and do not separate the executions.

CodePipeline offers SUPERSEDED (default), QUEUED and PARALLEL modes. QUEUED and PARALLEL require pipeline type V2, and PARALLEL does not support stage rollback.

• ARequest a lower account-level concurrent build quota so that fewer builds run at the same time

  Incorrect

  An account quota would limit every project, not only this one.

• BRaise the project's build timeout so that queued runs have more time to finish

  Incorrect

  A longer timeout does not reduce how many runs hit the database at once.

• CSet the project's concurrent build limit to three in its project settings

  Correct

  The project-level limit caps how many builds of this project run at the same time, up to the account limit.

• DSet each pipeline that starts the project to the QUEUED execution mode so that its runs wait for one another

  Incorrect

  QUEUED mode processes one pipeline's executions one by one, but the many separate pipelines still start the project at the same time.

A CodeBuild project can restrict its number of concurrent builds. The value cannot exceed the account's concurrent build limit and leaves other projects unaffected.