Understand the GitLab Workspace and Repository Model GITLAB-CERTIFIED-GIT-ASSOCIATE Practice Questions (Page 3)

Questions 11–15

1. 11application · easy

   A developer wants to contribute to a public GitLab project but does not have write access. The developer has forked the project, made changes on a new branch, and pushed the branch to their fork. What is the next step to propose these changes to the original project's maintainers?

   • AAdd the maintainers as members to the fork and ask them to merge the branch.
   • BSend a pull request via email to the maintainers.
   • CCreate a merge request from the fork's branch to the original project's default branch.
   • DUse 'git push' directly to the original project's repository.
   Reveal Solution Discussion Select an answer first
2. 12foundation · easy

   In GitLab, what is the purpose of a tag in a repository?

   • ATo temporarily hide a set of commits from the history
   • BTo create a new branch for feature development
   • CTo store a copy of the repository on a remote server
   • DTo mark a specific commit as a release or important milestone
   Reveal Solution Discussion Select an answer first
4. 13foundation · easy

   In GitLab, which visibility level allows any user on the GitLab instance to view the project without authentication?

   • AProtected
   • BPrivate
   • CPublic
   • DInternal
   Reveal Solution Discussion Select an answer first
5. 14expert · medium

   A developer has a local repository that was cloned from a GitLab project. They have made several commits on a local branch and want to publish this branch to the remote repository. However, they are not sure if the branch name already exists on the remote. What is the safest command to push the branch and set up tracking without overwriting an existing remote branch?

   • Agit push --force origin <branch-name>
   • Bgit push -u origin <branch-name>
   • Cgit push origin HEAD
   • Dgit push origin <branch-name>:<branch-name>
   Reveal Solution Discussion Select an answer first
6. 15expert · hard

   A company is migrating from a monolithic repository to a microservices architecture. They have a single GitLab group with multiple projects. The team wants to maintain a single CI/CD pipeline configuration across all microservices, but each service should be versioned independently. They also need to ensure that a change to one service does not trigger the pipeline for other services. Which GitLab workspace and repository model best supports this?

   • AUse a single project with a single branch and use Git submodules for each microservice.
   • BUse a separate project for each microservice, and use a shared CI/CD template or include file for the common pipeline configuration.
   • CUse a single project with multiple directories, one for each microservice, and use CI/CD rules to limit pipeline triggers.
   • DUse a single project with multiple branches, one for each microservice.
   Reveal Solution Discussion Select an answer first