CertArea
All GitLab exams

Free GitLab Certified Fundamentals Associate practice test: 30 questions with answers

30 original questions for GitLab Certified Fundamentals Associate, drawn from every topic area. Answer each one to see whether you got it right and why. No sign-up.

Free questions
30
Full bank
112 questions
Real exam
50 questions, 75 min
Passing score
75%

GitLab Certified Fundamentals Associate exam guide: topics, cost and format

All 30 GitLab Certified Fundamentals Associate questions with answers

The same questions as the test above, grouped by exam topic. Open any question to see the answer and explanation.

Essential GitLab Functions (5 questions)

  1. Question 1

    A top-level group named Platform has a subgroup named Payments that contains several projects. A developer is added to Platform with the Maintainer role. What access does the developer get in Payments?

    1. ANo access to Payments until the developer is also invited to the subgroup separately
    2. BGuest access only, because subgroups cap any inherited role at the Guest level
    3. COwner rights over Payments, because a parent group Maintainer always gains ownership of every subgroup
    4. DMaintainer access to the projects in Payments, inherited from the parent group membership
    Show answer and explanation
    Correct answer: D

    Group memberships are inherited by subgroups and the projects inside them, so the developer keeps Maintainer access in Payments. The other options are wrong because no separate invitation is needed, Maintainer does not turn into Owner, and inherited roles are not capped at Guest.

  2. Question 2

    Which project visibility level lets signed-in users of the GitLab instance see a project while keeping it hidden from anonymous visitors?

    1. APrivate, so only explicitly added project members can see the project and its content
    2. BPublic, so anyone on the internet, including anonymous visitors, can browse the project
    3. CInternal, so any signed-in user of the instance can see the project
    4. DProtected, so only users holding the Maintainer role or higher can see the project
    Show answer and explanation
    Correct answer: C

    Internal visibility lets any signed-in user of the instance view the project while anonymous visitors cannot. Private limits access to explicit members, Public exposes the project to anonymous visitors, and Protected is not a project visibility level.

  3. Question 3

    A developer's merge request description contains the line 'Closes #42', and issue #42 is in the same project. What happens to the issue when the merge request is merged into the default branch?

    1. AIssue #42 is locked so nobody can comment on it, but its open status does not change
    2. BIssue #42 is deleted from the project, and its comments are moved into the merge request
    3. CIssue #42 is closed automatically once the merge request lands in the default branch
    4. DIssue #42 stays open until a Maintainer manually confirms the link to the merge request in the issue sidebar
    Show answer and explanation
    Correct answer: C

    Closing keywords such as Closes #42 in a merge request description or commit message close the referenced issue when the change is merged into the default branch. The other options describe actions GitLab does not take: deleting the issue, locking it, or requiring manual confirmation.

  4. Question 4

    A developer wants reviewers to look at a merge request early, but the work is not finished and must not be merged yet. What is the most appropriate step?

    1. AAdd the Draft: prefix to the merge request title to mark it as not ready for merging
    2. BClose the merge request and reopen it only after the implementation is complete and tested
    3. CTurn on merge when pipeline succeeds so the merge is delayed until the work is finished
    4. DApply a label named wip and ask reviewers to ignore the merge request until the label is removed
    Show answer and explanation
    Correct answer: A

    A Draft: prefix in the title marks the merge request as work in progress, and GitLab does not allow it to be merged until the prefix is removed. A label does not block merging, closing and reopening does not help reviewers, and merge when pipeline succeeds would merge the change automatically once the pipeline passes.

  5. Question 5

    Which statement about protected branches in a GitLab project is correct?

    1. AThey delete the branch automatically after every merge request is approved, so the history stays short
    2. BThey make all files on the branch read-only for every project member, including Owners and Maintainers, until a release is tagged
    3. CThey control which roles can push to or merge into a branch such as main, reducing unreviewed changes
    4. DThey copy the branch into a separate archive project that is not allowed to receive new commits
    Show answer and explanation
    Correct answer: C

    Protected branches let a project restrict which roles can push to or merge into a branch, which helps keep main free of unreviewed changes. They do not delete branches, make files read-only for everyone, or create archive projects.

GitLab CI/CD Functions (5 questions)

  1. Question 6

    A pipeline defines three stages: build, test, and deploy. The build stage has a job named compile, the test stage has jobs named unit and lint, and the deploy stage has a job named publish. In what order does GitLab run them by default?

    1. AAll four jobs start at the same time because the stages keyword only labels jobs and does not control order
    2. BThe compile job runs first, then unit and lint run in parallel, and publish waits for them to succeed
    3. CThe unit and lint jobs run first, then compile, and publish runs last to prepare the environment
    4. Dpublish runs first to reserve the environment, then compile, and then unit and lint in sequence
    Show answer and explanation
    Correct answer: B

    Stages run in the order they are listed, and jobs inside one stage run in parallel. A later stage starts only after the jobs of the earlier stage succeed, so compile goes first and publish goes last. The other options ignore stage order or reverse it.

  2. Question 7

    Which two statements about the needs keyword in .gitlab-ci.yml are correct? (Choose two.)

    1. AA job with needs can start as soon as the jobs it names finish, without waiting for the whole previous stage
    2. BA job with needs pauses until a user clicks a play button in the pipeline graph before it starts
    3. CA job with needs downloads the artifacts of the jobs it names by default, unless that download is turned off
    4. DA job with needs can run only on runners that carry the tag listed in its needs entry
    Show answer and explanation
    Correct answer: A, C

    The needs keyword lets a job start early once the jobs it names finish, and those jobs' artifacts are downloaded by default. A manual play button is set with when: manual, and needs does not select runners by tag.

  3. Question 8

    A build job creates a compiled binary that a deploy job in a later stage must download. Separately, the team wants a folder of downloaded dependencies reused across pipeline runs to speed up installs. Which keywords fit these two needs?

    1. Acache for the compiled binary, and artifacts for the dependency folder that is reused across pipeline runs
    2. Bartifacts for both needs, because cache is only available inside the job that created the files, so reuse is impossible
    3. Cartifacts for the compiled binary, and cache for the dependency folder that is reused across pipeline runs
    4. Dcache for both needs, because artifacts can only hold the test reports that a pipeline produces
    Show answer and explanation
    Correct answer: C

    Artifacts are files passed from a job to later jobs in the same pipeline and can be downloaded from it, while cache keeps files such as dependency folders for reuse by later pipeline runs. The other options swap the two keywords or misstate what each one is for.

  4. Question 9

    A team wants one job to run only on the default branch and only when files under the docs/ folder change. Which configuration achieves this?

    1. AAn allow_failure setting of true, so the job runs on every branch and its failures never appear in the pipeline
    2. BA rules block with an if clause that matches the default branch and a changes list that includes docs/**
    3. CA when: manual setting, so the job waits for a click on every pipeline before it starts
    4. DAn image keyword that points at a documentation container, so the job starts only inside that container
    Show answer and explanation
    Correct answer: B

    A rules block can combine an if condition on the default branch with a changes list, so the job is added only when both match. allow_failure, when: manual and image do not limit a job to a branch or to file changes.

  5. Question 10

    A single job in a pipeline failed because of a temporary network problem. The rest of the pipeline is fine. What is the most direct way to run only that job again?

    1. ACancel the whole pipeline and push an empty commit so that every job runs again from the first stage
    2. BDelete the failed job from the .gitlab-ci.yml file and push the change so the job restarts
    3. CSelect the Retry action on the failed job in the pipeline view, which reruns only that job
    4. DRebase the default branch onto the failed commit so GitLab reschedules the job automatically
    Show answer and explanation
    Correct answer: C

    The Retry action on a failed job reruns only that job, which is the most direct fix for a transient failure. Cancelling and pushing an empty commit reruns everything, deleting the job from the file removes it, and rebasing the default branch does not schedule jobs.

GitLab Overview (5 questions)

  1. Question 11

    A team wants every merge request to trigger automatic builds and tests, so that a broken change is found within minutes of being pushed. Which practice does this describe?

    1. AContinuous deployment, where every change that passes the tests is released to production automatically
    2. BContinuous delivery, where a person approves each change before it is released to production
    3. CIssue tracking, where each new change is logged as a ticket and assigned to a reviewer for triage
    4. DContinuous integration, where changes merge often and each one is automatically built and tested
    Show answer and explanation
    Correct answer: D

    Continuous integration means changes are merged often and each one is built and tested automatically, which is what this team wants. Continuous deployment and continuous delivery are about releasing to production, and issue tracking does not run builds or tests.

  2. Question 12

    Which statement best describes continuous delivery?

    1. ACode is always kept in a releasable state, and a person decides when a tested change goes to production
    2. BEvery change that passes the automated pipeline is released to production with no manual approval step
    3. CDevelopers push changes to a feature branch and test them only once, just before the sprint review
    4. DProduction systems are monitored around the clock, and operations staff receive automated alerts whenever errors appear
    Show answer and explanation
    Correct answer: A

    Continuous delivery keeps the code releasable at all times, with a person choosing the moment to release to production. The no-approval option describes continuous deployment, while the other two describe a late testing habit and production monitoring, which are not the definition.

  3. Question 13

    Which two capabilities are built into the single GitLab application? (Choose two.)

    1. AReplacing the Git protocol with a proprietary version control system that clones cannot read
    2. BReviewing proposed code changes through merge requests with comments and approvals
    3. CProviding the cloud servers on which every customer application runs in production by default
    4. DRunning build and test jobs defined in a .gitlab-ci.yml file for each pipeline
    Show answer and explanation
    Correct answer: B, D

    GitLab covers source code management, merge request review and CI/CD pipelines in a single application, as part of the DevSecOps toolchain. It builds on standard Git rather than replacing it, and it does not supply production hosting by default, so those options are wrong.

  4. Question 14

    During a code review, a reviewer wants a specific teammate to look at one line of a merge request without opening a new issue. What should the reviewer do?

    1. AExport the diff as a PDF and send it to the teammate by email outside of GitLab
    2. BCreate a new epic and assign it to the teammate so the line is tracked separately
    3. CAttach a milestone to the merge request so the teammate receives a notification about it
    4. DType @ followed by the teammate's username in a comment on that line of the merge request
    Show answer and explanation
    Correct answer: D

    Mentioning a user in a comment on the relevant line notifies that person and keeps the discussion inside the merge request. Epics and milestones are planning items, and an exported PDF moves the discussion outside GitLab.

  5. Question 15

    A team wants dependency and code security checks to run on every merge request, so that vulnerabilities are caught before the code reaches the main branch. Which DevSecOps principle does this follow?

    1. AShift left, which moves security testing earlier in the development lifecycle
    2. BContinuous deployment, which releases every passing change to production automatically
    3. CCanary release, which sends a small share of production traffic to a new version first
    4. DBlue-green switching, which keeps two identical production environments ready for cutover
    Show answer and explanation
    Correct answer: A

    Shift left means moving security checks earlier, into merge requests and pipelines, so issues are found while changes are still small. The other options are release and deployment strategies rather than a principle for catching vulnerabilities earlier.

GitLab Security Functions (5 questions)

  1. Question 16

    Which scanner type inspects source code for security weaknesses without running the application?

    1. ADAST, which sends requests to a running application and observes how it responds
    2. BContainer scanning, which checks the packages inside a built image against known vulnerabilities
    3. CSAST, static application security testing, which analyzes source code without running it
    4. DLicense compliance, which checks the open-source licenses used by project dependencies
    Show answer and explanation
    Correct answer: C

    SAST, or static application security testing, analyzes source code without executing the application. DAST tests a running application, container scanning checks image contents, and license compliance checks licenses rather than security weaknesses.

  2. Question 17

    A security team wants to test a staging web application while it is running, by sending HTTP requests to its pages and forms, to find issues such as reflected cross-site scripting. Which scanner should they enable?

    1. ADependency scanning, which lists third-party libraries and reports known vulnerabilities in them
    2. BDAST, dynamic application security testing, which probes the running application from outside
    3. CSAST, which reads the source code of the application and flags risky patterns in it
    4. DLicense compliance, which checks the licenses of packages before they are added to a project
    Show answer and explanation
    Correct answer: B

    DAST tests a running application from the outside by sending requests, which is how it finds issues such as reflected cross-site scripting. SAST reads source code without running it, and dependency scanning and license compliance do not test the live application at all.

  3. Question 18

    A team wants to turn on GitLab's maintained SAST scanning in a project without writing scanner jobs by hand. Which addition to .gitlab-ci.yml does this?

    1. AA custom job named sast whose script runs a manually installed scanner binary and uploads no reports
    2. BA security: enabled: true key at the top of the file, which switches on every scanner at once
    3. CA scanner entry in the Monitor settings, which runs SAST after every push to the default branch
    4. DAn include entry with template: Security/SAST.gitlab-ci.yml, which adds the maintained SAST jobs
    Show answer and explanation
    Correct answer: D

    Including GitLab's Security/SAST.gitlab-ci.yml template adds the maintained SAST jobs without hand-written scanner code. The custom job, the invented security key and the Monitor settings do not provide maintained SAST jobs.

  4. Question 19

    Which configuration lets GitLab read scanner output and show the findings in a merge request widget and the vulnerability report?

    1. AA cache entry that stores the scanner's working directory between pipeline runs for faster scans
    2. BAn artifacts entry under reports, such as sast, that points to the JSON file the scanner writes
    3. CA pages entry that publishes the scanner's HTML output as a static site for the team
    4. DAn environment entry that names a staging server so each scan result is stored against it
    Show answer and explanation
    Correct answer: B

    The reports keyword inside artifacts tells GitLab which file holds the scanner output, and GitLab then displays the findings in the merge request and the vulnerability report. Cache, pages and environment entries do not tell GitLab to read scan results.

  5. Question 20

    A developer accidentally commits a cloud access key to a feature branch. The team wants the pipeline to flag committed credentials like this one. Which scanner should be enabled?

    1. ASecret detection, which looks for hard-coded credentials and tokens in the repository's changes
    2. BContainer scanning, which checks the operating system packages inside the built image
    3. CDAST, which sends requests to the running application to look for exposed endpoints
    4. DLicense compliance, which checks the open-source licenses of the dependencies in the project
    Show answer and explanation
    Correct answer: A

    Secret detection scans the repository for hard-coded credentials such as access keys and tokens, which is what this case needs. License compliance, container scanning and DAST look for different things and do not target committed secrets.

GitLab Agile Planning (5 questions)

  1. Question 21

    What is the main purpose of labels on issues and merge requests in GitLab?

    1. ATo categorize items so they can be filtered, searched, and shown as lists on issue boards
    2. BTo give a user Maintainer permissions on a project without changing group membership
    3. CTo store the binary files that a pipeline produces so that they can be downloaded later
    4. DTo set a hard deadline that automatically publishes a release when the date is reached
    Show answer and explanation
    Correct answer: A

    Labels categorize issues and merge requests, and they drive filtering, searching and board lists. Artifacts, permissions and release deadlines are handled by other features, so those options do not describe labels.

  2. Question 22

    A team plans a two-week release and wants to group the related issues and merge requests under one target, with a start date and a due date for the whole group. Which GitLab feature should the team use?

    1. AA milestone with a start date and due date, assigned to the related issues and merge requests
    2. BA label named release-2 with a due date typed into its description field for tracking
    3. CA board list named release-2, which holds issues only and cannot record any dates
    4. DA wiki page that lists the items and their target dates, updated by hand each sprint
    Show answer and explanation
    Correct answer: A

    A milestone groups issues and merge requests under one target and supports start and due dates. Labels have no due dates, board lists only organize cards, and a wiki page is not linked to the work items.

  3. Question 23

    A product owner wants to see work move from To Do to Doing to Done by dragging cards between columns. Which feature provides this view?

    1. AAn issue board whose lists are based on labels, so moving a card updates its label
    2. BA milestone burndown chart, which moves each card's position as the issues are closed
    3. CThe project activity feed, which lets users drag commits into columns to show progress
    4. DA snippet collection that is reordered each time an issue changes status in the project
    Show answer and explanation
    Correct answer: A

    An issue board shows cards in lists, and lists based on labels let teams move work through stages by dragging cards, which updates the label. The burndown chart, activity feed and snippets do not offer drag-and-drop columns of issues.

  4. Question 24

    Which two statements about milestones in GitLab are correct? (Choose two.)

    1. AA milestone can have a start date and a due date
    2. BOnly instance administrators can create milestones, and project members cannot
    3. CIssues and merge requests can be assigned to a milestone to group them for planning
    4. DAdding a milestone to a merge request replaces the approval rules for that merge request
    Show answer and explanation
    Correct answer: A, C

    Milestones support start and due dates, and issues and merge requests can be assigned to them for planning. Project members can create milestones, and a milestone does not change the approval rules of a merge request.

  5. Question 25

    A team lead wants a board where each column shows the work assigned to one person, so the workload of each team member is visible at a glance. How should the board be set up?

    1. ACreate a snippet for each person and link it to the board so the work appears in its column
    2. BUse a milestone burndown chart, which places each person's issues in its own separate column
    3. CCreate board lists based on assignees, with one list for each team member
    4. DAdd a due date to each member's profile, which automatically groups their issues in the board
    Show answer and explanation
    Correct answer: C

    Issue board lists can be based on assignees, so each column shows the issues assigned to one team member. Snippets, burndown charts and profile due dates do not create board columns for people.

Package and Release Functions (5 questions)

  1. Question 26

    A job builds a Docker image and must push it to the Container Registry of the same project. Which predefined CI/CD variable gives the registry image path for that project?

    1. A$CI_REGISTRY_IMAGE, which holds the Container Registry path for the project
    2. B$CI_COMMIT_SHA, which holds the full commit hash that triggered the pipeline
    3. C$CI_PIPELINE_ID, which holds the numeric identifier of the current pipeline run
    4. D$CI_JOB_NAME, which holds the name of the job as written in the pipeline configuration
    Show answer and explanation
    Correct answer: A

    CI_REGISTRY_IMAGE is the predefined variable that holds the base address of the project's Container Registry. The other variables hold a commit hash, a pipeline ID and a job name, none of which is a registry path.

  2. Question 27

    A team generates a static documentation website in a CI job and wants GitLab Pages to publish it. Which requirement must that job meet?

    1. AThe job must upload the site to the Package Registry as a generic package before Pages can serve it
    2. BThe job must be named deploy-docs and send the site to an external web server over SSH
    3. CThe job must run only on tags whose names begin with release, so the site is not built on every push
    4. DThe job must be named pages and produce its site in a public directory saved as an artifact
    Show answer and explanation
    Correct answer: D

    GitLab Pages looks for a job named pages whose artifacts include a public directory containing the site. The other options invent requirements, such as a Package Registry upload, a deploy job name or a tag-only rule, that Pages does not need.

  3. Question 28

    A platform team builds an internal npm library and wants other projects in the company to install it with the usual npm install command. Where should the package be published in GitLab?

    1. AIn pipeline artifacts, which are kept as downloadable files for a limited time only
    2. BIn the Container Registry, as an image layer that contains the library source code
    3. CIn GitLab Pages, as a static site that serves the library's compiled files over HTTP
    4. DIn the Package Registry, as an npm package that other projects can install from the project
    Show answer and explanation
    Correct answer: D

    The Package Registry stores npm packages, so other projects can install the library with the standard npm tooling. The Container Registry stores images, Pages hosts websites, and artifacts are temporary job outputs, so none of them acts as an npm package source.

  4. Question 29

    A developer has merged unfinished code into the main branch, but the new checkout flow must stay hidden from customers until it is ready. The team wants to turn it on later without another deployment. What should they use?

    1. AA protected branch on a separate checkout branch, which keeps the code out of the deployment
    2. BA feature flag around the new checkout code, which can be switched on later without redeploying
    3. CA pipeline schedule that deploys the checkout code at a fixed time each week
    4. DA milestone with a start date, which hides the issues linked to the checkout work from customers
    Show answer and explanation
    Correct answer: B

    Feature flags wrap code so it can be turned on or off at runtime, which separates deployment from release. Protected branches, pipeline schedules and milestones do not control whether customers see a feature in production.

  5. Question 30

    Which two are recognized deployment strategies for releasing a new version of an application? (Choose two.)

    1. ACanary deployment, which sends a small share of users to the new version before a full rollout
    2. BRebase deployment, which rewrites the commit history of the production branch before each release
    3. CCleanup-policy deployment, which removes old image tags from the registry on a schedule
    4. DBlue-green deployment, which switches traffic between two identical environments
    Show answer and explanation
    Correct answer: A, D

    Canary and blue-green deployments are established strategies: canary exposes a small share of users first, and blue-green switches traffic between two environments. Rewriting branch history and registry cleanup policies are not deployment strategies.