CI/CD and Git practice questions

Answer: D

Continuous delivery keeps every passing change in a deployable state and leaves the final production release as a manual decision. Continuous deployment would release automatically with no click. Continuous integration only covers merging and building or testing changes frequently. Continuous monitoring observes running systems and is not a release practice.

Answer: B

GitHub Actions only reads workflow files from the .github/workflows directory of the repository. The repository root is not scanned. The .github/actions directory is a conventional place for local composite actions, not for workflows. A folder named for Azure Pipelines is irrelevant to GitHub.

Answer: A

git revert creates a new commit that applies the inverse of the bad commit, so history only moves forward and no one’s clone breaks. git reset –hard followed by a force push rewrites shared history and breaks other clones. Dropping the commit in an interactive rebase also rewrites history. git stash only shelves uncommitted local changes.

Answer: C

Squash merge combines all commits of the pull request into a single new commit on the target branch. A merge commit keeps every branch commit and adds a merge commit. Rebase and fast-forward keeps a linear history but still adds each individual commit. Cherry-pick copies selected commits and is not a pull request merge type.

Answer: C

A build validation policy queues the configured pipeline for each pull request and blocks completion until it succeeds. Requiring linked work items enforces traceability, not a passing build. A CI trigger on main runs after the merge, which is too late. Limiting merge types to squash controls history shape, not quality.

Answer: A

OpenID Connect lets the workflow request a short-lived token: create a federated credential on a Microsoft Entra app registration trusting the repository, grant the job the id-token: write permission and use azure/login with the client, tenant and subscription IDs. A client secret stored in a repository variable or as an encrypted secret is still a long-lived credential. A publish profile file is also a stored credential.

Answer: D

An environment with an approval check pauses any deployment job that targets the environment until the named approvers respond. A branch policy requiring reviewers gates code in pull requests, not deployments. Marking a variable as secret only hides its value. A scheduled trigger starts runs at a time and does not ask anyone to approve.

Answer: B

Build once, deploy many: publish the build output as an artifact and deploy that same immutable artifact to every stage, so what was tested is what is released. Rebuilding per stage can produce different binaries from changed dependencies or tooling. Skipping tests makes things worse. Building on a developer machine removes repeatability.

Answer: C

Git LFS stores small pointer files in the repository and keeps the large content on an LFS server, so history and clones stay small while the files remain versioned. Adding them to .gitignore stops versioning them. A shallow clone only limits how much history one person downloads and does not change how the files are stored. Compressing the files into a zip still stores each large version in history.

Answer: A

A canary release exposes the new version to a small, controlled share of traffic first and expands it as metrics stay healthy. Blue-green switches all traffic from one full environment to the other at once. A rolling deployment replaces instances in batches and does not let you set a traffic percentage. A big-bang release replaces everything at once with no gradual exposure.

Answer: B

The key must be treated as compromised, so revoke and rotate it first, then remove it from history with a tool such as git filter-repo or BFG and have everyone re-clone. Deleting the file in a new commit leaves the key in history. Rewriting history without revoking leaves a key that may already have been copied. Making the repository private does not undo earlier exposure.

Answer: D

The reflog records where HEAD and branches pointed, so git reflog shows the lost commit hashes and git reset –hard to the right entry (or a new branch at that hash) brings them back. git log follows the current branch and no longer lists the commits. git stash pop restores stashed changes, which these are not. git revert HEAD adds a commit that undoes the latest commit and recovers nothing.

Answer: B

Deploy to a staging deployment slot, warm and test it, then swap it with production; if problems appear, swap back. Deploying straight to the production slot gives no test stage and causes restarts. Stopping the app during deployment causes downtime. A second App Service plan with a manual DNS change is slower, riskier to roll back and unnecessary when slots exist.

Answer: A

Merge the unfinished code to main behind a feature flag that is off, so integration stays continuous and release is decoupled from deployment. A long-lived feature branch delays integration and invites painful merges. Holding back merges until the end gives the same problem. Deploying to production and hoping users do not notice is not a control.

Answer: C

A custom condition replaces the default succeeded() check, so it must include it: and(succeeded(), eq(variables[‘Build.SourceBranch’], ‘refs/heads/main’)). The branch test alone would also run after failed stages. always() runs regardless of outcome and branch. Build.SourceBranch holds the full ref, so comparing it to the short name main never matches.