Building Robust CI/CD Pipelines in AWS CodePipeline

Correct Answer: B.

The power of AWS Step Functions is orchestrating workflow-driven actions and joining other services based on logic in the workflow.

A robust way to decouple AWS Step Functions and AWS CodePipeline are via an AWS Lambda function triggered by AWS CodePipeline and acting in the interim between workflow actions and the pipeline itself.

As of February 2020, AWS Step Functions support AWS CloudWatch Logs to log workflow execution history, which makes it possible to centralize logging to this service as required in the problem description.

Incorrect Answers:

Options A, D are incorrect because AWS Lambda functions are not the most robust approach to handle workflow-driven actions in this scenario.

Option C is incorrect because the problem description states using AWS CloudWatch Logs as a centralized logging service instead of Amazon S3

AWS CloudWatch Logs is supported as of February 2020 by AWS Step Functions to log workflow execution history.

References:

https://aws.amazon.com/blogs/devops/using-aws-step-functions-state-machines-to-handle-workflow-driven-aws-codepipeline-actions/ https://aws.amazon.com/about-aws/whats-new/2020/02/aws-step-functions-supports-cloudwatch-logs-standard-workflows/

Option B is the most robust approach to follow to create a CI/CD pipeline in AWS CodePipeline that can handle complex cases, asynchronous workflow-driven actions, and centralized logging to CloudWatch Logs.

This approach involves creating an AWS Step Functions state machine that can handle workflow-driven actions through specific, lean single-purpose AWS Lambda functions. A state machine is a workflow that allows for the execution of specific tasks based on events or input from other AWS services. Each task within the state machine can be executed by an AWS Lambda function that is designed to perform a specific function.

In this approach, the CodePipeline deploy action triggers an AWS Lambda function that decouples the Step Functions state machine and the pipeline itself. This ensures that the pipeline can continue functioning even if the state machine fails or encounters errors.

To deal with centralized logging, the state machine can be configured to log workflow execution history to CloudWatch Logs. This allows for the monitoring of the pipeline's execution history in a centralized location, making it easier to troubleshoot any issues that arise.

Option A is not as robust as option B since it only involves creating an AWS Lambda function to handle workflow-driven actions and configure a CodePipeline deploy action to trigger the same AWS Lambda function. Although it is possible to configure an AWS Step Function to log workflow execution history to CloudWatch Logs, this approach does not take advantage of the benefits that a state machine can provide, such as better visibility into the pipeline's execution.

Option C is not the best approach because although it involves creating an AWS Step Functions state machine to handle workflow-driven actions through specific, lean single-purpose AWS Lambda functions and configuring a CodePipeline deploy action to trigger an AWS Lambda function that decouples the Step Functions state machine and the pipeline itself, it suggests using an Amazon S3 bucket to store all logs since there is no integration between AWS Step Functions and Amazon CloudWatch Logs. This approach is not as optimal since it would require additional steps to retrieve logs and may not provide real-time visibility into the pipeline's execution.

Option D is not the best approach since it only involves creating an AWS Lambda function to handle workflow-driven actions and configuring a CodePipeline deploy action to trigger the same AWS Lambda function. Additionally, using an Amazon S3 bucket to store all logs from CloudWatch Logs is not as optimal since it would require additional steps to retrieve logs and may not provide real-time visibility into the pipeline's execution.