🌍 Git & Version Control · flashcards
Git & Version Control Hosting Platforms and DevOps Integration Flashcards
51 question-and-answer cards covering Hosting Platforms and DevOps Integration as it is examined in Git & Version Control. 24 of them are printed below, taken from across the deck — no signup, no paywall on the preview.
24 sample cards from the Hosting Platforms and DevOps Integration deck
Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.
Define Continuous Integration (CI).
CI is the practice of frequently merging developers' code changes into a shared mainline, where each integration is automatically built and tested to detect integration errors early.
What core problem does Continuous Integration aim to solve?
"Integration hell"—the difficulty and bugs that arise when developers work in isolation for long periods and merge large, divergent changes infrequently.
Distinguish Continuous Integration, Continuous Delivery, and Continuous Deployment.
CI automatically builds/tests every change. Continuous Delivery keeps the code always in a deployable state with release requiring a manual approval. Continuous Deployment automatically releases every passing change to production with no manual gate.
What events are most commonly used to trigger CI pipelines?
A `push` to a branch and the opening/updating of a `pull_request` (merge request); also scheduled runs, tags, and manual dispatch.
Why trigger a pipeline on a pull request rather than only on push to main?
To validate proposed changes before they merge—running tests and status checks on the merge result so broken code is caught prior to entering the protected/default branch.
In GitHub Actions, what is the difference between the `pull_request` and `pull_request_target` triggers regarding security?
`pull_request` runs in the context of the PR's fork with a read-only token and no access to secrets by default (safer for untrusted code), whereas `pull_request_target` runs in the base repository's context with secrets access, which is riskier for forked PRs.
What is a status check on a pull request?
A status check is an automated pass/fail (or pending) report—from CI, tests, linters, or external services—attached to a commit/PR that indicates whether the change meets required conditions before merging.
What is the role of automated testing within a CI pipeline?
It automatically executes unit, integration, and other test suites on each change to verify correctness, prevent regressions, and provide the fast feedback that gates merges and deployments.
What is a "required status check" in branch protection?
A status check that must pass (report success) before a pull request can be merged into the protected branch; if it fails or is pending, merging is blocked.
Name three common continuous deployment strategies.
Blue-green deployment, canary deployment, and rolling deployment (also feature flags / dark launches).
Describe a blue-green deployment.
Two identical production environments (blue = current, green = new) run in parallel; traffic is switched from blue to green once the new version is verified, enabling instant rollback by switching back.
Describe a canary deployment.
The new version is rolled out to a small subset of users/servers first; metrics are monitored, and if healthy the rollout gradually expands to 100%, otherwise it is rolled back—limiting the blast radius of failures.
Describe a rolling deployment.
Instances are updated to the new version incrementally in batches, replacing old instances gradually so the service stays available, without needing a full duplicate environment.
Why sign commits, and what two mechanisms does Git support for it?
Signing cryptographically proves a commit's author and integrity (verified authorship, tamper-evidence). Git supports signing with GPG keys and with SSH keys (and X.509/S-MIME).
Which Git config and flag enable signing a commit with GPG?
Set the key with `git config user.signingkey <KEYID>` and sign with `git commit -S` (or enable `commit.gpgsign true` to sign automatically).
How do you tell Git to use an SSH key instead of GPG for signing commits?
Set `git config gpg.format ssh` and `git config user.signingkey <path-to-ssh-public-key>`, then sign with `git commit -S` (or `commit.gpgsign true`).
What does a "Verified" badge on a GitHub commit indicate?
That the commit's signature was validated against a key the author registered with GitHub and matches the committer identity, confirming the commit is genuinely from that person and unaltered.
What is secret scanning on a hosting platform?
An automated feature that inspects commits and repository contents for exposed credentials (API keys, tokens, passwords) using known patterns, alerting maintainers—or blocking the push (push protection)—when a secret is detected.
What are Dependabot / dependency alerts?
Automated alerts that notify maintainers when a project depends on packages with known security vulnerabilities (from an advisory database), often accompanied by automated pull requests to bump to a patched version.
What are branch protection rules?
Configurable constraints on important branches (e.g., main) that enforce policies such as requiring pull request reviews, passing status checks, signed commits, linear history, and preventing force pushes or deletion.
What is the purpose of a CODEOWNERS file?
It defines individuals or teams responsible for specific files/paths using glob patterns; matching owners are automatically requested for review on pull requests touching those paths, and can be required for approval.
Where can a CODEOWNERS file be located in a GitHub repository?
In the repository root, in the `.github/` directory, or in the `docs/` directory.
What is an audit log in the context of an organization or repository?
A chronological, tamper-resistant record of significant actions and events (member changes, permission changes, repo creation/deletion, settings changes) used for security monitoring, compliance, and accountability.
What access-control model do platforms like GitHub use to limit what members can do, and what principle should guide its configuration?
Role-based access control (RBAC) via roles/permission levels assigned to users and teams, guided by the principle of least privilege—granting only the minimum access needed for a task.
What this deck covers
The Hosting Platforms and DevOps Integration deck follows the Git & Version Control Hosting Platforms and DevOps Integration syllabus — 4 chapters and 15 topics — so questions land on material that is genuinely examinable rather than trivia around it. That works out to roughly 12.8 cards per chapter.
Answers are written to be recallable, not just readable — averaging about 184 characters, which is long enough to carry the reasoning and short enough to say out loud.
A deck like this earns its keep on the second and third pass. Read the syllabus first so you know the shape of the subject, then use the cards to find the specific facts that have not stuck.
Hosting Platforms and DevOps Integration flashcards FAQ
How many Hosting Platforms and DevOps Integration flashcards are in this Git & Version Control deck?
51 cards. This page previews 24 of them, sampled evenly across the deck so you can judge the difficulty before installing anything.
Are these Git & Version Control flashcards free?
Yes. The preview here is free to read with no signup, and the full 51-card deck is free inside the Examius app.
What do the Hosting Platforms and DevOps Integration cards cover?
They follow the Git & Version Control Hosting Platforms and DevOps Integration syllabus — 4 chapters and 15 topics — so the questions track what is actually examinable.
How should I use these flashcards?
Read the syllabus first so you know the shape of the subject, then drill the deck. Examius schedules each card with spaced repetition, so cards you keep missing come back sooner and ones you know drift further apart.