Jenkins as the Build Provider in AWS CodePipeline

Answer - C.

This is given in the AWS Documentation.

As a best practice, when you use a Jenkins build provider for your pipeline's build or test action, install Jenkins on an Amazon EC2 instance and configure a separate EC2 instance profile.

Make sure the instance profile grants Jenkins, only the AWS permissions required to perform tasks for your project, such as retrieving files from Amazon S3.

The instance profile provides applications running on an Amazon EC2 instance with the credentials to access other AWS services.

As a result, you do not need to configure AWS credentials (AWS access key and secret key).

Option A is incorrect because the "codepipeline:*" permission is not suitable as it allows more actions than required.

Option B is incorrect because an instance profile should be used to assign the permissions for Jenkins.

There is no need to add access keys.

Option D is incorrect because when adding Jenkins as the build provider in AWS CodePipeline, users cannot install Jenkins on a Lambda function.

For more information on best practices of AWS CodePipeline, see below.

https://docs.aws.amazon.com/codepipeline/latest/userguide/best-practices.html

The best practice for integrating Jenkins as the Build provider in AWS CodePipeline is option C, which involves installing Jenkins on an Amazon EC2 instance and configuring its instance profile to grant only the AWS permissions required to perform tasks for your project.

Option A is not a recommended approach because granting the EC2 instance role the "codepipeline:*" permission provides it with too many permissions, which can result in security risks. It's generally best practice to provide the minimum required permissions for a given task to reduce potential attack surface.

Option B is also not recommended as it involves managing access keys for the Jenkins server, which can be a security risk if not properly secured. Access keys can be used by unauthorized individuals to gain access to AWS resources if they are stolen or compromised.

Option D is not a feasible approach because Jenkins requires a server environment to run, which is not provided by AWS Lambda. Lambda functions are designed for short-lived, event-driven computing tasks, while Jenkins requires a persistent, long-running environment.

Therefore, the recommended approach is to use option C, where Jenkins is installed on an EC2 instance and its instance profile is configured to grant only the required permissions for the specific project. This ensures that the Jenkins server only has the necessary permissions to perform its designated tasks and reduces potential security risks.