A university research computing group hosts its code on a self-managed GitLab server inside the campus network. The server is reachable from the group's Amazon VPC over a site-to-site VPN, but not from the internet.
The first AWS CodePipeline pipeline cloned the repository in a CodeBuild step with a personal access token pasted into an environment variable. Security has asked that no long-lived tokens sit in build configuration, and that every pipeline use a managed connection that can be scoped and revoked.
Pipelines should start on pushes to the release branch, and the pipeline's service role should be allowed to use only that one connection.
Which approach meets these requirements?
Choose one answer.
AA. Store the GitLab personal access token in AWS Secrets Manager, and have the source stage call a Lambda function that clones the repository with the token and uploads a zip archive to Amazon S3.
BB. Create an S3 bucket that receives a nightly export of the repository from GitLab, and point the pipeline's source action at the newest object in that bucket.
CC. Install the GitLab Runner on an EC2 instance in the campus VPC, and have the runner register each build and write its results to the pipeline's artifact bucket.
DD. Create an AWS CodeConnections host for the GitLab server with a VPC configuration that reaches it, create a connection on that host, and let the pipeline's service role use only that connection's ARN.
Show the answer and explanation
Answer: D
A. Wrong: This works, but the team would keep a long-lived token in Secrets Manager and maintain a clone function. It also bypasses the managed connection, so pipelines cannot start on pushes and access is harder to scope and revoke. Learn more: What is AWS Secrets Manager? (opens in a new tab)
B. Wrong: A nightly copy means the pipeline builds a snapshot, not the commit that was pushed. Release branches would lag behind GitLab, which misses the requirement to start runs on pushes. Learn more: Amazon S3 Event Notifications (opens in a new tab)
C. Wrong: A GitLab Runner executes jobs for GitLab CI pipelines. It does not supply the source stage of a CodePipeline pipeline, so this design swaps in a different system and adds EC2 instances to patch.
D. Right: Correct. A host resource with a VPC configuration lets CodeConnections reach a self-managed GitLab server on a private network, and the connection holds the authorization instead of the build configuration. Scoping the role to the connection's ARN limits which pipelines can use it. Learn more: Create a connection to GitLab self-managed (opens in a new tab)
Explanation
CodeConnections supports self-managed GitLab through a host resource, and a VPC configuration on the host lets it reach a server that is only on a private network. The connection replaces tokens in build configuration and can start the pipeline on pushes, and scoping the pipeline role to the connection's ARN limits its use. Stored tokens, nightly copies and self-hosted runners each leave a credential in the wrong place or do not provide a source stage at all.
Want more on Source repositories and Git connections? The 5 full-length practice sets have 5 more Source repositories and Git connections questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →