Git & Version Control Hosting Platforms and DevOps Integration Syllabus

Hosting Platforms and DevOps Integration syllabus — full chapter and topic list

Expand any chapter to see its topics and sub-topics. This is the whole examinable outline for Hosting Platforms and DevOps Integration in Git & Version Control, not a summary of it.

1. 1

   GitHub Essentials

   4 topics

   • Repositories, Organizations, and Teams
   • Issues, Projects, and Milestones
   • GitHub CLI and Codespaces
   • GitHub Actions Overview
2. 2

   GitLab and Bitbucket

   3 topics

   • GitLab Repositories and Pipelines
   • GitLab CI/CD Basics
   • Bitbucket and Atlassian Integration
3. 3

   CI/CD with Git

   4 topics

   • Continuous Integration Concepts
   • Triggering Pipelines on Push and PR
   • Automated Testing and Status Checks
   • Continuous Deployment Strategies
4. 4

   Security and Governance

   4 topics

   • Signing Commits with GPG and SSH
   • Secret Scanning and Dependency Alerts
   • Branch Protection Rules and CODEOWNERS
   • Audit Logs and Access Control

Hosting Platforms and DevOps Integration flashcards for Git & Version Control

21 of 51 cards from the Hosting Platforms and DevOps Integration deck — real questions with worked answers.

1. In Git hosting platforms, what is a repository?

   A repository (repo) is a storage location containing a project's files together with the complete version history (the Git object database and refs), enabling tracking, branching, and collaboration on that project.

2. On GitHub, what is an Organization and how does it differ from a personal account?

   An Organization is a shared account that owns repositories collectively rather than by one person. It provides centralized ownership, member management, teams, and granular access control, whereas a personal account is owned and controlled by a single user.

3. What is a Team within a GitHub Organization, and what is its main purpose?

   A Team is a group of organization members that can be granted repository permissions collectively and @mentioned. It simplifies access management and can be nested to mirror org structure and cascade permissions.

4. List the standard repository permission (access) levels GitHub grants to collaborators/teams.

   Read, Triage, Write, Maintain, and Admin, in increasing order of privilege.

5. What is the difference between a public, private, and internal repository?

   Public repos are visible to everyone; private repos are visible only to explicitly granted users/teams; internal repos are visible to all members of the enterprise but not the outside public.

6. On GitHub, what is an Issue used for?

   An Issue is a trackable unit for reporting bugs, requesting features, or discussing tasks. It supports labels, assignees, milestones, comments, and cross-references, and can be closed automatically by commits/PRs.

7. What is a Milestone in issue tracking, and what does it group?

   A Milestone groups related issues and pull requests toward a shared goal or release, tracks their completion percentage, and can carry a due date.

8. What are GitHub Projects (the Projects boards) used for?

   Projects are customizable planning boards (table, board/Kanban, or roadmap views) that organize and track issues and pull requests across repositories using custom fields, statuses, and automation.

9. Which keywords in a commit message or PR description will automatically close a linked issue when merged to the default branch?

   close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved (e.g., "Fixes #42").

10. What is the GitHub CLI (`gh`) and one common use?

    `gh` is GitHub's official command-line tool for interacting with GitHub from the terminal—e.g., creating and reviewing pull requests (`gh pr create`), managing issues, releases, and running workflows without the web UI.

11. What is a GitHub Codespace?

    A Codespace is a cloud-hosted, containerized development environment (a dev container running on a VM) that provides a ready-to-code VS Code workspace configured for a repository, accessible from the browser or locally.

12. Which file customizes the environment of a GitHub Codespace or dev container?

    The `devcontainer.json` file (typically in a `.devcontainer` directory), which defines the container image, features, extensions, ports, and setup commands.

13. What is GitHub Actions?

    GitHub Actions is GitHub's built-in CI/CD and automation platform that runs workflows in response to repository events, defined as YAML files that execute jobs made up of steps on runners.

14. In GitHub Actions, define the hierarchy: workflow, job, step, and action.

    A workflow contains one or more jobs; each job runs on a runner and contains ordered steps; a step either runs a shell command or invokes an action (a reusable unit of code).

15. Where must GitHub Actions workflow files be stored?

    In the `.github/workflows/` directory of the repository, as `.yml` or `.yaml` files.

16. In a GitHub Actions workflow, what does the `on:` key specify?

    It defines the events that trigger the workflow, such as `push`, `pull_request`, `schedule` (cron), `workflow_dispatch` (manual), or `release`.

17. By default, do jobs in a GitHub Actions workflow run in parallel or sequentially, and how do you enforce order?

    Jobs run in parallel by default; you enforce sequential ordering with the `needs:` key, which makes a job wait for the listed jobs to complete successfully.

18. On GitLab, what defines a CI/CD pipeline, and in which file?

    A GitLab pipeline is defined in the `.gitlab-ci.yml` file at the repository root, specifying stages and jobs executed by GitLab Runners.

19. In GitLab CI/CD, what is the relationship between stages and jobs?

    A pipeline is divided into ordered stages; jobs in the same stage run in parallel, and a stage begins only after the previous stage's jobs succeed (unless configured otherwise).

20. In GitLab CI/CD, what executes the jobs defined in `.gitlab-ci.yml`?

    GitLab Runners—agents (shared, group, or project-specific) that pick up jobs and run them using an executor such as Docker, Shell, or Kubernetes.

21. In GitLab CI/CD, what is the purpose of the `script:` keyword in a job?

    `script:` lists the shell commands the runner executes for that job; it is the only required keyword for a job to run.

See more Hosting Platforms and DevOps Integration flashcards →

Planning Hosting Platforms and DevOps Integration for Git & Version Control

Hosting Platforms and DevOps Integration (Git & Version Control) FAQ