AWS CodePipeline

47 questions

Question 41Question

A developer is configuring a custom stage action in AWS CodePipeline that invokes an AWS Lambda function to perform integration testing. Arrange the following events in the correct chronological order, from the moment the Lambda action is initiated by the pipeline to the transition of the pipeline to the next stage.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order starts with CodePipeline transitioning the action to In Progress and generating a Job ID, followed by CodePipeline invoking the Lambda function with the payload. Next, the Lambda function executes and retrieves the Job ID, then calls PutJobSuccessResult with the Job ID, and finally, CodePipeline receives the result and transitions the action status to Succeeded.
The correct chronological order starts with CodePipeline generating the Job ID and transitioning the action to In Progress. Next, CodePipeline invokes the Lambda function, passing the Job ID in the event payload. The Lambda function then runs its code, retrieves the Job ID from the event payload, and finishes its tasks. Finally, the function calls the PutJobSuccessResult API with the Job ID, allowing CodePipeline to mark the action as Succeeded and proceed.

Step-by-Step Solution

1
Initiate the action in the pipeline
CodePipeline transitions the Lambda action to In Progress and generates a unique Job ID containing execution details.
AWS CodePipeline manages the lifecycle of the action and creates a tracking Job ID for the execution.
2
Invoke the Lambda function
CodePipeline invokes the Lambda function asynchronously, passing the job event as the JSON payload.
This transfers execution control to the Lambda function and provides the necessary context, including the Job ID.
3
Process the custom logic and parse the event payload
The Lambda function runs its code and extracts the Job ID from the input event object.
The function must have the Job ID in memory to report the outcome back to CodePipeline.
4
Submit the success callback
The Lambda function calls the PutJobSuccessResult API operation using the AWS SDK, referencing the Job ID.
CodePipeline requires an explicit API call (PutJobSuccessResult or PutJobFailureResult) to update the status of the action; otherwise, the stage will hang and eventually time out.
5
Complete the stage transition
CodePipeline transitions the action status to Succeeded and proceeds to the next stage or action.
The received API call confirms the successful completion of the custom action.

Key Concept

AWS CodePipeline integration with AWS Lambda requires the Lambda function to explicitly return a success or failure status by calling the PutJobSuccessResult or PutJobFailureResult API operation using the Job ID provided in the invocation event payload.
Question 42Question

A developer is configuring a continuous delivery pipeline in AWS CodePipeline that consists of Source, Build, and Deploy stages. The developer needs to configure the pipeline to use a custom build specification file located in a subdirectory (build/buildspec.yml) of the source repository. Additionally, the developer must pass a dynamically generated container image tag from the Build stage (AWS CodeBuild) to the Deploy stage (AWS CloudFormation). Which two actions must the developer perform to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Specify the custom buildspec path 'build/buildspec.yml' in the AWS CodeBuild project configuration.; Define a variable namespace in the CodePipeline build action configuration, and reference the output variable in the subsequent deploy stage using the namespace syntax.

Answer

To satisfy the requirements, the developer must specify the custom buildspec path in the CodeBuild project settings and use CodePipeline's native variable namespace feature in the build action configuration to reference output variables in the downstream deployment stage.
Specifying the custom buildspec path in the AWS CodeBuild project configuration is necessary because CodeBuild only looks at the root folder by default. Defining a variable namespace in the CodePipeline build action enables downstream stages to access values like an image tag using variable namespace interpolation.

Step-by-Step Solution

1
Set the custom buildspec location in AWS CodeBuild.
The developer updates the CodeBuild project configuration so that it looks for the build specification file at 'build/buildspec.yml'.
By default, CodeBuild expects the buildspec.yml file to be located in the root of the source directory. Specifying the custom path prevents build initialization failures.
2
Export variables from CodeBuild to CodePipeline.
The developer configures the build action in CodePipeline with a namespace, which acts as a container for output variables generated during the build execution.
Assigning a namespace enables downstream deployment actions to consume exported variables using the namespace references.

Key Concept

AWS CodePipeline Variable Namespaces and CodeBuild Configuration
Question 43Question

A developer is configuring a continuous delivery pipeline in AWS CodePipeline in Account A. The pipeline is designed to deploy a web application to an Amazon ECS cluster located in Account B. The pipeline uses an Amazon S3 bucket in Account A as its artifact store. During the deployment phase, the deployment action in Account B fails with an Access Denied error when attempting to read the build artifact from the S3 bucket in Account A. Which configuration change will resolve this issue?

Show answer & explanation

Answer: Configure the S3 bucket in Account A to use a customer managed key (CMK) in AWS KMS, and update both the S3 bucket policy and the KMS key policy to grant the deployment role in Account B access.

Answer

Configure the S3 bucket in Account A to use a customer managed key (CMK) in AWS KMS, and update both the S3 bucket policy and the KMS key policy to grant the deployment role in Account B access.
The correct answer is to configure the S3 bucket in Account A with a customer managed key (CMK) and grant read and decrypt access to the Account B role. AWS CodePipeline stores artifacts in S3. For cross-account deployments, the action in the target account must read these artifacts. Since the default S3 KMS key cannot be shared across AWS accounts, the artifact bucket must be encrypted with a Customer Managed Key, and its policy must trust the target account role.

Step-by-Step Solution

1
Identify the root cause of cross-account artifact decryption failure.
The default AWS managed S3 key (aws/s3) cannot be used for cross-account operations.
AWS managed keys cannot have their key policies modified to grant access to external accounts.
2
Create and configure a Customer Managed Key (CMK) in AWS KMS within Account A.
A CMK is created with a key policy that explicitly grants decrypt permissions to the deployment IAM role in Account B.
A customer managed key allows external accounts to be granted usage permissions.
3
Update the S3 bucket policy in Account A.
The bucket policy allows the deployment IAM role in Account B to perform GetObject operations.
Both S3 resource permissions and KMS key permissions must be satisfied for successful retrieval.

Key Concept

Cross-account artifact access in AWS CodePipeline requires using a customer managed key (CMK) in AWS KMS and granting permissions to the target account's deployment role in both the S3 bucket policy and the KMS key policy.
Question 44Question

A development team is integrating an on-premises security scanning tool as a custom action in AWS CodePipeline. A custom worker application runs on-premises and processes the security scanning tasks.

Arrange the steps in the correct chronological order that the custom action worker must execute to process and complete a job in CodePipeline.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The custom worker must first poll for available jobs, acknowledge the retrieved job, process the job by downloading artifacts and running the scan, and finally report the success status back to CodePipeline.
The correct sequence starts with polling for jobs, followed by acknowledging the job to prevent duplicate executions, then downloading the artifacts and running the scan, and finally reporting the success status back to CodePipeline.

Step-by-Step Solution

1
Poll for jobs
The worker receives a job token and details from CodePipeline.
Since the worker is on-premises and CodePipeline cannot initiate connection, the worker must poll CodePipeline for new jobs.
2
Acknowledge the job
The job status is set to in-progress in CodePipeline.
This prevents other worker instances from picking up the same job and verifies that the worker is actively handling it.
3
Process job workloads
Input artifacts are processed, and the security scan runs.
The worker retrieves input artifacts from S3 using the credentials in the job details, then performs the security scan.
4
Put job success result
CodePipeline transitions the stage action to succeeded.
CodePipeline requires an explicit API call to mark the action as complete before it can trigger the next stage.

Key Concept

AWS CodePipeline Custom Actions and the Worker Lifecycle
Estimated Time:1m 30s
Question 45Question

A developer is configuring a continuous delivery pipeline in AWS CodePipeline. The pipeline has a deploy stage that deploys a serverless API, followed by an integration test stage that runs an AWS Lambda function. The Lambda function must retrieve a database password that requires automatic rotation every 30 days. Additionally, the Lambda function needs permissions to execute and log to Amazon CloudWatch.

Which two configurations should the developer implement to satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager and configure automatic rotation.; Configure the Lambda function's IAM execution role with a trust policy that allows the lambda.amazonaws.com service principal to assume the role.

Answer

Store the database password in AWS Secrets Manager and configure automatic rotation, and configure the Lambda function's IAM execution role with a trust policy that allows the lambda.amazonaws.com service principal to assume the role.
Storing the password in AWS Secrets Manager satisfies the requirement for automatic 30-day rotation, as Secrets Manager natively handles automatic rotation via integrated Lambda templates. Additionally, configuring the Lambda function's execution role with a trust policy that allows lambda.amazonaws.com ensures the Lambda service can assume the role at runtime to perform its actions and write logs to CloudWatch.

Step-by-Step Solution

1
Determine the appropriate secret storage service.
AWS Secrets Manager is chosen over Systems Manager Parameter Store.
Only Secrets Manager provides native support for automatic rotation of secrets.
2
Determine the trust relationship for the Lambda execution role.
The trust policy must allow lambda.amazonaws.com to assume the role.
AWS Lambda needs to assume the execution role at runtime to execute the function and perform actions like logging to CloudWatch.

Key Concept

AWS CodePipeline integration with AWS Lambda and secure credential management using AWS Secrets Manager.
Question 46Question

A developer is maintaining a continuous delivery pipeline in AWS CodePipeline that consists of Source, Build, and Deploy stages. The Deploy stage uses AWS CodeDeploy to release updates to an Amazon ECS service. The developer needs to temporarily prevent new builds from being deployed to ECS while the production database undergoes a scheduled maintenance window. However, developers must still be able to commit code changes, and the pipeline must continue to run the Source and Build stages to validate the builds. Which configuration change should the developer make to achieve this goal with the least administrative effort?

Show answer & explanation

Answer: Disable the transition from the Build stage to the Deploy stage in the CodePipeline console.

Answer

Disable the transition from the Build stage to the Deploy stage in the CodePipeline console.
Disabling the transition between stages in AWS CodePipeline prevents new executions from entering the target stage (Deploy) while allowing preceding stages (Source, Build) to complete successfully. The pipeline execution stops at the boundary, and once the maintenance is complete, the transition can be re-enabled to allow the latest build artifact to progress to the Deploy stage automatically.

Step-by-Step Solution

1
Identify the requirement to pause deployments at a specific stage while allowing earlier stages (Source, Build) to continue execution.
Determine that stopping the entire pipeline or causing errors in subsequent stages is undesirable.
The requirement states that developers must still commit code and runs must occur in the Source and Build stages.
2
Evaluate CodePipeline's built-in control mechanisms.
Recognize that stage transitions can be disabled to prevent executions from moving from one stage to another.
Disabling transitions is a native feature that cleanly halts the pipeline progress at a boundary without failing the running execution or the pipeline itself.
3
Configure the transition control in the AWS Management Console or via the AWS CLI.
Disable the transition between the Build and Deploy stages, and re-enable it after the database maintenance is complete.
This satisfies the requirement with the least administrative effort and without altering IAM roles or application logic.

Key Concept

AWS CodePipeline Stage Transitions
Question 47Question

A developer is configuring a continuous delivery pipeline in AWS CodePipeline. The pipeline builds a database migration package in AWS CodeBuild and then runs a post-migration check using an AWS Lambda function. The CodeBuild project must retrieve a database password stored as a SecureString in AWS Systems Manager Parameter Store. The Lambda function must report its execution status back to CodePipeline.

Arrange the execution steps in the correct chronological order from start to finish to ensure the pipeline runs successfully without permission or credential failures.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The pipeline first pulls the source code, then CodeBuild retrieves and decrypts the database password from Parameter Store, next the Lambda service assumes the Lambda execution role to run, and finally the Lambda function invokes PutJobSuccessResult to notify CodePipeline of completion.
The correct order requires pulling the source code first, then allowing CodeBuild to assume its service role and decrypt the SecureString from Parameter Store using AWS KMS. After CodeBuild completes, CodePipeline invokes the Lambda function. The Lambda service assumes the execution role (which requires a trust relationship with lambda.amazonaws.com), and once the code runs, the function must explicitly report success to CodePipeline using PutJobSuccessResult.

Step-by-Step Solution

1
Source artifact generation
Source code is successfully fetched and packaged.
AWS CodePipeline requires a source artifact to trigger downstream stages.
2
CodeBuild retrieves secure credentials
The decrypted database password is loaded into CodeBuild's environment.
CodeBuild needs credentials to run the migration; the CodeBuild service role must have permissions to decrypt the KMS key used by the SecureString parameter.
3
Lambda function execution
The Lambda service assumes the execution role and runs the verification code.
The Lambda execution role must trust the lambda.amazonaws.com service principal to execute the code.
4
CodePipeline status notification
CodePipeline receives a success result and completes the action.
Asynchronous Lambda actions in CodePipeline do not auto-complete; they require a PutJobSuccessResult call to advance the pipeline.

Key Concept

AWS CodePipeline execution flow, secure parameter retrieval, and service role trust configurations.
Estimated Time:1m 30s
PreviousPage 3 / 3
AWS CodePipeline Practice Questions — AWS Certified Developer - Associate — Page 3 | Examkin