GitLab CI/CD Associate study plan
GitLab CI/CD Associate · Give each week a clear focus.
8 weeks · About 6 hours per week
Pipeline configuration and CI/CD YAML fundamentals
Write a complete .gitlab-ci.yml from memory containing global keywords (stages, default, workflow, include) and at least four jobs, then validate it with the CI Lint tool and fix every reported error.
Map each top-level keyword to its scope (global vs job-level) and record a one-line rule for when to use default: instead of repeating keys in every job.
Refactor a duplicated job definition into a hidden job template using extends and YAML anchors, and explain in writing why extends merges hash keys while anchors replace them.
Split one monolithic configuration into three files joined with include:local and include:template, and verify with the merged-configuration view that ordering and overrides behave as expected.
Your checkpoint
A lint-clean, multi-file pipeline repository with a README table mapping every keyword used to its scope and override behavior.
Pipeline configuration and CI/CD YAML fundamentals & Job execution, stages, and pipeline flow control
Build a pipeline with five stages and at least two jobs per stage, then predict the execution order before running it and compare against the actual pipeline graph.
Convert one job to a parallel:matrix job with three variable combinations and confirm each instance appears as a separate job with its own variables.
Implement needs: DAG links that let a downstream job start before the previous stage finishes, and document the resulting graph difference versus stage-only ordering.
Configure rules: with if, changes, and exists clauses to include or exclude jobs, and verify each rule path by pushing commits that trigger and skip them.
Add allow_failure and when: manual to at least two jobs and record how each affects pipeline status and blocking of later stages.
Your checkpoint
A screenshot-free written trace (text pipeline graph plus job logs excerpts) proving DAG ordering, matrix expansion, and rules-based inclusion all work as designed.
Job execution, stages, and pipeline flow control
Write rules that replace only/except entirely in one migrated job and list three behavioral differences between the two keywords.
Implement workflow:rules to prevent duplicate pipelines when both branch and merge request events fire, and prove it by opening an MR and checking only one pipeline runs.
Use interruptible plus auto-cancel redundant pipelines so a superseded commit's pipeline is cancelled, and confirm the cancellation in job logs.
Configure retry with when: runner_system_failure and script_failure, then force a failure to observe the retry count and final status.
Chain a child pipeline with trigger:include and pass variables to it, verifying the parent-child relationship in the pipeline view.
Your checkpoint
A pipeline that demonstrably cancels redundant runs, retries on the configured failure class, and spawns a child pipeline with passed variables, documented in a short changelog.
Variables, secrets, and protected configuration
Define variables at global, job, and script level and demonstrate precedence by printing the same variable name from all three scopes.
Create CI/CD variables in project settings marked protected and masked, then prove a protected variable is unavailable on an unprotected branch and that a masked value is redacted in logs.
Use variables:description with pre-filled options to build a manually triggered pipeline whose input changes job behavior.
Inject a secret via a file-type variable and read it from disk in the script instead of echoing it, and confirm the value never appears in job logs.
Explain in writing how protected branches, protected tags, and protected environments each gate access to protected variables, with one concrete misconfiguration example for each.
Your checkpoint
A variables reference document plus a demo pipeline showing scope precedence, masking, and protected-variable denial on an unprotected branch.
Caching and artifacts
Configure cache:key:files tied to a lockfile and show that the cache is reused on an unchanged lockfile and rebuilt when it changes.
Compare cache and artifacts by building a job that uses both, then document which one is available to later-stage jobs and which is only restored locally by the runner.
Set artifacts:expire_in and artifacts:paths, then download and inspect the artifact archive from the job page to confirm contents and expiry metadata.
Use dependencies and needs:artifacts to control which jobs download artifacts, and verify a job with dependencies: [] downloads nothing.
Configure a fallback cache key with two keys and demonstrate the fallback being pulled when the primary key misses.
Your checkpoint
A cache-and-artifact matrix document recording hit/miss behavior, expiry, and download scope for at least four job configurations, backed by real job logs.
Runners, executors, and job scheduling
Register a local runner with the docker executor and a shell executor, then run the same job on both and compare environment differences such as image availability and cleanup.
Set tags on runners and jobs and prove that an untagged job does not land on a tagged-only runner, using the job's runner assignment in the log header.
Configure concurrent, limit, and request_concurrency on a runner and observe queueing behavior when more jobs are submitted than the concurrency allows.
Use resource_group to serialize deployments so two jobs targeting the same resource never run simultaneously, and confirm the waiting state in the pipeline view.
Write a runner selection troubleshooting note covering tag mismatch, runner offline, and protected-runner restrictions on unprotected branches.
Your checkpoint
A runner configuration sheet listing executor, tags, concurrency, and protected status for each runner, plus a log-backed demonstration of resource_group serialization.
Troubleshooting pipelines and merge request pipelines & Job execution, stages, and pipeline flow control
Configure a merge request pipeline with workflow:rules and rules:if on CI_PIPELINE_SOURCE, and verify jobs run only in MR context and not on branch pushes.
Diagnose three deliberately broken pipelines (YAML syntax error, unknown keyword, missing script) and record the exact error message and the fix for each.
Reproduce a job that fails only in CI due to environment differences (missing variable, wrong image, no network) and document the debugging steps used to isolate it.
Use CI_DEBUG_TRACE or set -x selectively to debug a failing script, then explain the security risk of leaving debug tracing enabled.
Read a failed job's trace to identify whether the failure came from the script, the runner system, or a timeout, and map each to the correct retry:when value.
Your checkpoint
A troubleshooting playbook of at least six real failure scenarios, each with symptom, root cause, fix, and the log line that confirmed the diagnosis.
Pipeline configuration and CI/CD YAML fundamentals & Job execution, stages, and pipeline flow control & Variables, secrets, and protected configuration & Caching and artifacts & Runners, executors, and job scheduling & Troubleshooting pipelines and merge request pipelines
Assemble one capstone project that exercises all six domains: multi-file YAML, DAG with matrix, protected masked variables, cache plus artifacts, tagged runners, and an MR pipeline with rules.
Complete a timed 60-question self-test across all domains and review every wrong answer to a specific keyword or concept gap.
Rewrite from memory the ten keywords you missed most often and validate each in a scratch pipeline.
Audit the capstone for anti-patterns (duplicated config, unpinned images, secrets in plain variables, over-broad rules) and fix each finding.
Your checkpoint
A public-ready capstone repository with a one-page architecture summary and a scored self-test log showing at least 80 percent correct.
Milestones
Week 2: Can write a multi-stage pipeline with matrix and needs from a blank file and correctly predict the execution graph before running it.
Week 4: Can explain and demonstrate variable precedence, masking, and protected-variable denial without consulting notes.
Week 6: Can register a runner, assign jobs by tag, and explain executor trade-offs and concurrency limits in your own words.
Week 8: Capstone passes end to end and the timed self-test scores at least 80 percent with every miss traced to a named keyword or concept.