Source repositories and Git connections: DOP-C02 study notes and practice questions
What to know about Source repositories and Git connections for the DOP-C02 exam, from the SDLC Automation domain (22% of the exam guide), then 1 free question to test it. Part of the DOP-C02 study guide.
Source questions ask how to connect a repository to a pipeline securely and start runs on the right changes.
AWS CodeConnections
Formerly CodeStar Connections. Connects CodePipeline, CodeBuild and other services to GitHub, GitHub Enterprise Server, GitLab.com, self-managed GitLab and Bitbucket.
Uses an installed app and OAuth, so no personal access tokens are stored in pipelines.
Self-managed servers need a host resource; a VPC configuration on the host reaches a server on a private network.
Connections can be shared and controlled with IAM (codeconnections:UseConnection).
Source action outputs
Zip of the source (default): just the files at that commit.
Full clone: a Git clone reference so CodeBuild can run Git commands (history, tags); the build role then needs permission to use the connection.
Other sources
Amazon S3 objects (with versioning), started by EventBridge events.
Amazon ECR image pushes, started by EventBridge.
Branching strategy
Trunk-based development with short-lived branches suits continuous delivery.
Pull request triggers run checks before merge; protected branches enforce reviews.
Tags can trigger release pipelines in V2.
CodeBuild on its own
CodeBuild webhooks with filter groups start builds on pull request or push events matching branches, file paths, actors or commit messages, which is handy for per-folder projects in a monorepo.
Git sync for infrastructure
CloudFormation Git sync keeps a stack updated from a template and deployment file in a repository through a connection.
Common traps
Storing a GitHub token in pipeline settings when a connection replaces it.
Opening a public route to a private GitLab server. Use a host with VPC configuration.
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 →