Day 5 - Week 5 Review: CodePipeline Integration Scenarios

A CodePipeline in the Tooling account deploys an ECS service to the Prod account. "The deploy Action started without any IAM Policy error, but the following error occurs during the Artifact download step: Client error: KMS key access denied when decrypting artifact". What are the cause and the fix?

• AThe Pipeline Service Role lacks sts:AssumeRole permission → add to the Pipeline Service Role an Identity Policy that allows AssumeRole on the Spoke Role ARN
• BThe Prod account's CrossAccountDeployRole is not a Principal in the Artifact S3 bucket policy → add a Principal allowing GetObject/PutObject to the bucket policy
• CThe Tooling account's KMS Key Policy lacks a kms:Decrypt allowance for the Prod account's CrossAccountDeployRole → modify the KMS Key Policy
• DThe ECS Task Execution Role and the Security Group of the target cluster are not aligned in the same VPC/subnet → reconfigure networking

A company manages 100 microservices in a single Git repository (monorepo). Each service has its own independent CodePipeline. A change in shared/auth/ must trigger all 100 pipelines, and a change in services/checkout/ must trigger only the checkout pipeline. What is the most appropriate V2 trigger configuration?

• AAnalyze the changed files with Lambda in a single pipeline and start the corresponding service pipeline
• BIn each service pipeline's filePaths.includes, include that service's path together with shared/auth/**
• CAnalyze the changed files in CodeBuild and start the corresponding pipeline with start-pipeline-execution
• DSplit Git branches per service

A financial services company has the requirement: "Every prod deployment must pass two automated gates: (1) the error rate alarm must be in OK state before deployment, (2) the error rate alarm must stay in OK state for 5 minutes after deployment. If either gate fails, automatically roll back." What is the most appropriate implementation?

• ATwo Manual Approval Actions so a person checks both
• BOn the Deploy Stage, set a CloudWatch Alarm Rule in beforeEntry (pre-deployment) and a CloudWatch Alarm Rule in onSuccess (post-deployment), both with result: ROLLBACK
• CPlace two Lambda Invoke Actions before and after the Deploy Action
• DMonitor the alarm state with an EventBridge Rule and roll back manually on failure

A team wants to implement a pattern where "only senior engineers have permission to approve prod deployments, and approval happens in Slack." When using AWS Chatbot, how can you control approval permission at a fine-grained user level?

• ARestrict the SNS Topic subscriptions to senior engineers' emails only
• BGive the Chatbot IAM Role the codepipeline:PutApprovalResult permission, but use a Condition to allow only specific pipeline ARNs
• CAWS Chatbot maps Slack users directly to IAM, so grant the permission to the senior engineers' IAM Users
• DImplement a custom Slack bot Lambda that checks the Slack user ID against the internal HR system and calls PutApprovalResult only if the user is a senior engineer

A State Machine using a Step Functions Action in CodePipeline must, during execution, "pause the deployment until a Change Request in the external change management system (ServiceNow) is approved." What is the most appropriate way for the State Machine to implement this wait?

• ASet WaitSeconds in a Task state inside the State Machine and retry every hour
• BThe waitForTaskToken pattern — pass the TaskToken to ServiceNow, and ServiceNow calls SendTaskSuccess upon approval
• CRun Lambda Invoke Actions and Step Functions Actions alternately
• DAdd a Manual Approval Action to the pipeline

A team managing its pipeline with CDK Pipelines wants to satisfy both the requirement "Manual Approval is mandatory before production deployment" and the requirement "staging deployment is fully automatic." How is this implemented in the CDK Pipelines code?

• ACreate two separate CDK Pipelines stacks (one for staging, one for production)
• Bpipeline.addStage(StagingStage) + pipeline.addStage(ProdStage, { pre: [new ManualApprovalStep('Approve')] })
• CBranch per environment with CloudFormation conditions
• DCheck the environment with a Lambda Invoke Action and trigger Manual Approval only for prod

The Pipeline is currently running in SUPERSEDED mode. What happens when 10 commits are pushed in quick succession?

• AThe 10 commits each create a separate execution, and all 10 are built and deployed with order guaranteed (the behavior of QUEUED mode)
• BThe last push cancels the previous in-progress execution into ABANDONED state and runs itself. As a result, only the last commit completes execution
• CThe 10 are queued in order and run serially one at a time, and all commit history is preserved (the behavior of QUEUED mode)
• D10 executions start in parallel at the same time and complete independently (the behavior of PARALLEL mode, requires independent targets)

A team set up a multi-Region pipeline. It builds in ap-northeast-2 and deploys to us-east-1 and eu-west-1 at the same time. If the deploy Actions in both Regions fail, what should you check?

• ACheck that an Artifact S3 bucket and a KMS key for each of us-east-1 and eu-west-1 are configured in the ArtifactStores array
• BCheck that VPC Peering is configured between Regions
• CCheck that Route 53 exists in all three Regions
• DCheck that Lambda functions are deployed in all three Regions

In one pipeline, a Build Action builds multiple microservice Docker images and the subsequent Deploy Action must use each image's tag. In a V2 Pipeline, what is the most appropriate approach?

• ACreate a separate pipeline for each service
• BDeclare SERVICE1_TAG, SERVICE2_TAG, etc. in CodeBuild's exported-variables and reference each from the Deploy Action in the form #{BuildVariables.SERVICE1_TAG}
• CInclude tags.json inside the Artifact zip file and have the Deploy Action read it
• DStore the environment variables in SSM Parameter Store and have the Deploy Action read them

In a hybrid pattern of "run PR builds and tests with GitHub Actions, and deploy to prod through CodePipeline only on a merge to the main branch," what is the most secure and simple way to implement the handoff from GitHub Actions to CodePipeline?

• ACall start-pipeline-execution directly from GitHub Actions with the AWS CLI (using an IAM User access key)
• BAssumeRole an IAM Role through an OIDC Provider from GitHub Actions → call start-pipeline-execution (temporary credentials)
• CPush an image to ECR → CodePipeline's Source Stage detects the ECR event → the pipeline starts automatically
• DPublish a message to an SNS Topic from GitHub Actions → Lambda calls start-pipeline-execution

While deploying to 50 accounts using StackSets in SERVICE_MANAGED mode, the following error occurs: "You must be an administrator of an Organization to use this operation." What is the cause?

• AThe StackSet template has a validation error, such as not specifying IAM CAPABILITY_NAMED_IAM, and fails before the Organizations permission check
• BA SERVICE_MANAGED StackSet can only be run from the Organizations management account (Management Account) or a Delegated Admin account, and the current executing account is neither
• CThe target accounts don't belong to Organizations so trusted access isn't enabled, and the integration between StackSets and Organizations is broken
• DThe StackSet's MaxConcurrentPercentage is too high and exceeds the concurrent deployment limit, surfacing as a permission error

A team faces the problem "a Lambda Invoke Action calls an external deployment system and it takes 45 minutes to complete." Which of the following is an INCORRECT way to get around Lambda's 15-minute limit while making the pipeline wait for the 45-minute completion?

• ASwitch to a Step Functions Action — handle the 45-minute work inside the State Machine
• BSet the Lambda timeout to 45 minutes and keep the existing approach
• CLambda immediately dispatches the work to SQS and calls put_job_success_result → a separate Worker notifies through a system external to the pipeline after completion (one-way, the pipeline treats it as success)
• DLambda immediately starts a Step Functions WaitForTaskToken execution and calls put_job_success_result → 45 minutes later the external system calls Step Functions' SendTaskSuccess