Top 30 CI/CD & Automation Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   A team merges into a shared branch daily with automated builds and tests. What is the single most important goal of this Continuous Integration practice?

   • aAutomatically deploying every passing build to production
   • bCatching bugs immediately after they are introduced
   • cKeeping the integrated codebase in a workable state at all times
   • dAutomating builds and tests to reduce manual integration work
   Show the answer

   Answer: c · Keeping the integrated codebase in a workable state at all times

   The defining goal of CI is maintaining a workable integrated codebase, not deployment, which is the realm of CD. While automation and bug detection are part of the practice, they are mechanisms and secondary benefits rather than the core objective.

   Read the full bite: What is CI, and what is its single most important goal?

2. Question 2 of 30

   A developer pushes to main, triggering a CI pipeline with build, test, and deploy stages. Which outcome best matches typical execution?

   • aThe GitLab server compiles and tests the code directly after each push, then deploys automatically without stage gating.
   • bA runner builds the project; then multiple runners execute test jobs in parallel; deployment proceeds only if every test job succeeds.
   • cThe build and test jobs run sequentially on a single runner, and the pipeline advances to deploy as long as the final job finishes.
   • dDeployment begins as soon as the first test job passes, because later stages do not need to wait for every job in the previous stage.
   Show the answer

   Answer: b · A runner builds the project; then multiple runners execute test jobs in parallel; deployment proceeds only if every test job succeeds.

   The card states that runners (not the Git server) execute jobs, that jobs within a stage run in parallel, and that a stage must succeed completely before the next stage begins. Option C is tempting because it correctly mentions sequencing but wrongly assumes everything runs sequentially on one machine and ignores the requirement that all jobs pass.

   Read the full bite: Describe the typical CI pipeline sequence from push to deploy

3. Question 3 of 30

   A company automatically deploys its internal tools to production but requires manual sign-off for its customer-facing payment service. What does this mixed strategy best demonstrate?

   • aContinuous Delivery is simply Continuous Deployment with unnecessary manual overhead that should eventually be removed.
   • bThe payment service lacks the automated testing maturity required for Continuous Deployment.
   • cThe payment service would use Continuous Deployment if it adopted feature flags for all new changes.
   • dDifferent applications may require different pipeline models based on business risk and compliance needs.
   Show the answer

   Answer: d · Different applications may require different pipeline models based on business risk and compliance needs.

   The card stresses that the choice between Continuous Delivery and Continuous Deployment is driven by business context, regulatory requirements, and blast radius, and that organizations often run a mixed model. Option A reflects the common misconception that Delivery is just an inferior version of Deployment, while the correct answer captures the intentional, risk-based pipeline design described in the card.

   Read the full bite: Continuous Delivery vs Continuous Deployment: key differences and choosing between them

4. Question 4 of 30

   Which approach aligns with the 'build once, deploy many' principle when handling environment-specific database URLs?

   • aEmbed the database URL directly in the application binary during compilation for each target environment
   • bMaintain separate Git branches per environment and build from the branch matching the target deployment
   • cRebuild the image for each environment, passing the database URL as a build argument to the Dockerfile
   • dBuild the container image once, then provide the database URL via environment variables at deployment time
   Show the answer

   Answer: d · Build the container image once, then provide the database URL via environment variables at deployment time

   The correct answer preserves artifact immutability by externalizing configuration and deploying the same binary everywhere. Option C is tempting because build arguments appear to parameterize deployments cleanly, but they force per-environment rebuilds that can introduce unverified dependency changes.

   Read the full bite: What is a build artifact and why build once deploy many crucial?

5. Question 5 of 30

   Which scenario best describes a genuine shift-left practice rather than a common misconception?

   • aHiring additional QA staff to write more regression tests executed the day before release
   • bIntegrating static analysis into pull request builds so vulnerabilities are caught before merge
   • cRunning the existing end-to-end suite on faster hardware to cut execution time from hours to minutes
   • dRequiring developers to manually perform user acceptance testing before they commit code
   Show the answer

   Answer: b · Integrating static analysis into pull request builds so vulnerabilities are caught before merge

   Integrating static analysis into pull request builds moves security feedback to the coding phase, which is the essence of shift left. Hiring more QA staff to test before release only increases test volume at the same late stage, confusing more testing with earlier feedback.

   Read the full bite: What does shift left mean in CI/CD, and give two concrete examples?

6. Question 6 of 30

   What key characteristic separates Infrastructure as Code from traditional imperative server scripting?

   • aIaC executes configuration steps sequentially each time a deployment runs
   • bIaC files are written in JSON or YAML rather than Bash or PowerShell
   • cIaC requires manual approval through ticketing systems before any changes apply
   • dIaC defines the desired end state and achieves idempotence through automated reconciliation
   Show the answer

   Answer: d · IaC defines the desired end state and achieves idempotence through automated reconciliation

   True IaC is defined by its declarative, idempotent model that lets the platform reconcile to a desired state, not by the file format used. While IaC definitions are often written in JSON or YAML, simply using those formats without declarative idempotence is still just scripting.

   Read the full bite: What is Infrastructure as Code (IaC), and how does it support CI/CD?

7. Question 7 of 30

   A platform team notices their pipeline is consistently green, but lead time for changes has grown from hours to days. Which diagnostic approach best aligns with value stream thinking?

   • aAudit production telemetry for elevated error rates that might be slowing releases
   • bInvestigate test flakiness causing repeated pipeline executions and hidden delays
   • cAdd more pre-merge quality gates to catch issues earlier and reduce rework
   • dDecompose lead time into queue, active pipeline, and post-pipeline release intervals
   Show the answer

   Answer: d · Decompose lead time into queue, active pipeline, and post-pipeline release intervals

   Decomposing lead time reveals whether waste hides in pre-merge queues, slow green stages, or post-merge deployment friction. Investigating test flakiness is tempting but misguided because a green pipeline rules out build failures as the cause.

   Read the full bite: Pipeline is green but lead time grows. Three areas to investigate?

8. Question 8 of 30

   Which scenario best illustrates a fundamental CI/CD difference between monoliths and microservices regarding blast radius and artifact indivisibility?

   • aA microservice team deploys a signed container side-by-side with the previous version, while a monolith rollback requires reverting the entire application
   • bA monolith pipeline rebuilds only the changed module while microservices require full system rebuilds for consistency
   • cA monolith uses per-service quality gates, while microservices rely on a single shared pipeline to reduce coordination overhead
   • dBoth architectures use federated short-lived credentials to prevent secret leakage across deployment stages
   Show the answer

   Answer: a · A microservice team deploys a signed container side-by-side with the previous version, while a monolith rollback requires reverting the entire application

   This captures the core idea that monoliths produce a single indivisible artifact requiring full rollback, while microservices support independent side-by-side deployments with signed images. Option C reverses these architectures and promotes the shared-pipeline anti-pattern the card explicitly warns destroys team autonomy.

   Read the full bite: How does your CI/CD strategy differ between monoliths and microservices?

9. Question 9 of 30

   Which characteristic of blue-green deployment most directly enables sub-minute rollback during a failed release?

   • aTraffic is shifted gradually to green while health metrics are monitored.
   • bGreen runs on the existing production instances alongside blue, separated by process or port isolation.
   • cThe blue environment remains fully operational and ready to receive traffic after cutover.
   • dDatabase schema changes are automatically rolled back by the orchestrator if green fails.
   Show the answer

   Answer: c · The blue environment remains fully operational and ready to receive traffic after cutover.

   The card states that because the old environment stays warm, rollback is a single traffic switch rather than a redeploy. Option A describes a canary release, which reuses the same infrastructure and gradually shifts traffic, making it a common misconception rather than true blue-green behavior.

   Read the full bite: Explain blue-green deployment, its prerequisites, and how it reduces deployment risk.

10. Question 10 of 30

    How does rebasing a feature branch onto main before a PR typically affect CI behavior compared to merging main into that branch?

    • aRebase keeps the original commit SHAs intact, so existing CI build results remain valid and only one new build runs.
    • bRebase generates new commit SHAs, causing CI to treat rebased commits as new pushes and queue multiple builds.
    • cRebase is safer than merge because it avoids merge commits, while merge pollutes history and causes redundant CI builds.
    • dMerge rewrites commit SHAs to create a linear history, invalidating previous CI results and triggering several new builds.
    Show the answer

    Answer: b · Rebase generates new commit SHAs, causing CI to treat rebased commits as new pushes and queue multiple builds.

    Rebase replays commits onto the target branch, which creates fresh SHAs that CI systems treat as brand-new pushes, burning compute minutes and orphaning prior build results, whereas merge preserves the original SHAs and triggers a single integration build. Option C is tempting because many beginners believe rebase is inherently cleaner or safer, but it actually requires force-push and breaks the one-to-one link between a commit and its CI result.

    Read the full bite: Difference between git merge and git rebase before a pull request

11. Question 11 of 30

    Why should a team not rely solely on a pre-push hook to guarantee that all tests pass before merging?

    • aIt is local-only, not cloned with the repository, can be skipped with --no-verify, and does not run for web or API commits.
    • bThe --no-verify flag only skips commit hooks, meaning pre-push checks cannot be bypassed by developers.
    • cIt must be committed to version control before Git will automatically execute it for everyone who clones the repository.
    • dIt runs on the remote server after the push completes, so it cannot prevent broken code from entering the repository.
    Show the answer

    Answer: a · It is local-only, not cloned with the repository, can be skipped with --no-verify, and does not run for web or API commits.

    Pre-push hooks reside in .git/hooks and are not copied on clone, can be bypassed with --no-verify, and do not run for web or API commits, so they cannot replace server-side enforcement. Option B is a tempting misconception: --no-verify skips pre-push hooks as well as commit hooks.

    Read the full bite: Describe using a pre-push Git hook for checks and its CI limitations.

12. Question 12 of 30

    In scaled Trunk-Based Development, what is the intended purpose of short-lived branches?

    • aTo isolate unfinished work for multiple days before integration
    • bTo replace trunk as the main collaboration branch for large teams
    • cTo publish versioned artifacts for downstream testing
    • dTo perform code review and validation before merging to trunk within hours
    Show the answer

    Answer: d · To perform code review and validation before merging to trunk within hours

    Scaled Trunk-Based Development uses short-lived branches solely for review and CI validation before same-day integration to trunk, not for artifact publication or long-term isolation. Keeping branches for multiple days violates the core principle of integrating at least every 24 hours and reintroduces merge risk.

    Read the full bite: Describe Trunk-Based Development principles and CI/CD benefits

13. Question 13 of 30

    How does Trunk-Based Development allow a team to continuously deploy an unfinished multi-week feature without exposing it to end users?

    • aMerge the incomplete code to main without tests because the dormant feature flag prevents users from ever executing the broken paths.
    • bKeep the feature on a long-lived branch until it is complete, merging to main only in the final week to avoid shipping incomplete work.
    • cDeploy the incomplete code only to a dedicated staging environment, promoting the artifact to production once the feature is fully built.
    • dWrap the new code paths in a feature flag that defaults to off in production, allowing the same binary to deploy continuously while keeping the feature hidden.
    Show the answer

    Answer: d · Wrap the new code paths in a feature flag that defaults to off in production, allowing the same binary to deploy continuously while keeping the feature hidden.

    Feature flags that default to off let teams integrate to main daily and deploy continuously while hiding incomplete behavior from users. The long-lived branch approach in option B contradicts Trunk-Based Development and reintroduces painful merge conflicts.

    Read the full bite: How do feature flags enable unfinished work in Trunk-Based Development?

14. Question 14 of 30

    When integrating a 50-commit stale branch that others may have pulled, which strategy best preserves shared history while validating pipeline stability?

    • aRebase onto main and force-push to maintain linear history, assuming collaborators can reset their local copies
    • bOpen a normal pull request with the conflicted branch so reviewers can assess the conflicts before you resolve them
    • cMerge main into the feature branch locally, resolve conflicts, run full tests, and open a draft PR before merging
    • dSquash the 50 commits and push directly to main after local conflict resolution, letting post-merge CI validate the result
    Show the answer

    Answer: c · Merge main into the feature branch locally, resolve conflicts, run full tests, and open a draft PR before merging

    Merging main into the feature branch preserves commit hashes and shared history, while a draft PR exercises the full CI pipeline without spamming reviewers or triggering merge queues prematurely. Rebasing and force-pushing is dangerous because it rewrites public history and breaks every collaborator's local environment.

    Read the full bite: How do you safely merge a 50-commit stale branch with conflicts?

15. Question 15 of 30

    After force-pushing a Git history rewritten with git-filter-repo to remove leaked credentials, why must teammates delete their local clones and re-clone rather than pull?

    • aA pull-and-push from their stale local branch would recontaminate the remote with the old commits containing the secret
    • bTheir local reflog retains the old commits, which could resurface the secret during a later merge
    • cgit-filter-repo changes commit timestamps so git pull produces irreconcilable merge conflicts
    • dBranch protection rules invalidate existing tracking branches until manually re-enabled on each clone
    Show the answer

    Answer: a · A pull-and-push from their stale local branch would recontaminate the remote with the old commits containing the secret

    The card explicitly warns that a teammate who pulls and then pushes from a stale local clone will reintroduce the old commits containing the secret back to the remote. While reflogs retain local history, the critical blast radius is recontamination of the shared repository, not a local merge issue.

    Read the full bite: How do you fully remove leaked credentials from Git history?

16. Question 16 of 30

    In a CI/CD context, why does merging an upstream dependency change naturally trigger the parent pipeline with git subtree but not with git submodules?

    • aSubtree maintains the dependency as a separate repository pointer, allowing the parent CI to detect upstream changes via remote polling.
    • bSubtree creates a new commit in the parent repository when merging the dependency, while submodules only update a pointer requiring a separate superproject commit.
    • cSubtree pins the parent to a specific dependency commit, forcing a rebuild, whereas submodules track the latest upstream branch lazily.
    • dSubmodules require recursive cloning that CI agents skip by default, preventing the trigger from propagating to the parent.
    Show the answer

    Answer: b · Subtree creates a new commit in the parent repository when merging the dependency, while submodules only update a pointer requiring a separate superproject commit.

    Subtree creates an actual commit in the parent repository when a dependency is merged, which CI systems detect as a repository change, whereas submodules only update a pointer file and require an explicit superproject commit to register. Distractor C describes a real submodule checkout failure mode but confuses clone-time behavior with pipeline trigger semantics.

    Read the full bite: Compare git submodules and git subtree for CI/CD

17. Question 17 of 30

    When is a build tool like Maven or Gradle necessary instead of invoking a compiler directly?

    • aWhen you need an orchestration layer that resolves dependencies, runs tests, and packages deployable artifacts
    • bWhen you need to replace the compiler with a faster code-translation engine
    • cWhen you want a tool to download libraries but not to orchestrate tests or packaging
    • dWhen you simply need a script that calls the compiler with the correct flags
    Show the answer

    Answer: a · When you need an orchestration layer that resolves dependencies, runs tests, and packages deployable artifacts

    A compiler only translates source into runnable code, whereas a build tool is an orchestration layer that handles dependency resolution, testing, and artifact packaging. Option D reflects the common misconception that a build tool is merely a wrapper around the compiler, while Option C wrongly reduces it to a package manager.

    Read the full bite: How do build tools differ from compilers or interpreters?

18. Question 18 of 30

    After establishing a baseline for a build time regression, what is the most effective next step before applying optimizations?

    • aParallelize independent jobs across additional runners immediately
    • bDecompose the pipeline into discrete stages and measure each stage's wall-clock time
    • cMigrate to a faster CI platform with more powerful default runners
    • dAudit compiler flags and build configurations for micro-optimizations
    Show the answer

    Answer: b · Decompose the pipeline into discrete stages and measure each stage's wall-clock time

    The card stresses measuring each stage to find the actual bottleneck before applying optimizations. A applies parallelism prematurely, B suggests a wasteful platform migration without diagnosis, and D targets micro-optimizations instead of structural issues.

    Read the full bite: Your build times increased significantly. How do you investigate and optimize?

19. Question 19 of 30

    After a build tool automatically resolves a diamond conflict, what is the most critical next step before considering the issue fixed?

    • aExclude the older transitive dependency from every direct dependency that pulled it in
    • bPin the resolved JARs directly into version control to prevent future changes
    • cUpgrade every dependency in the graph to the latest available version
    • dRun the full test suite and integration tests against the resolved version to detect binary incompatibility
    Show the answer

    Answer: d · Run the full test suite and integration tests against the resolved version to detect binary incompatibility

    The card emphasizes that semantic versioning does not guarantee binary compatibility, so the resolved version must be verified with full tests. Simply excluding the older transitive dependency or upgrading everything to latest skips runtime verification and risks hidden breaking changes.

    Read the full bite: Explain dependency management and diamond conflicts in automated builds

20. Question 20 of 30

    Which statement best captures a key operational tradeoff between ephemeral and persistent CI build agents?

    • aContainerized builds inherently require an ephemeral host lifecycle, so persistent containers are impractical
    • bEphemeral agents reduce security patching burden through short lifecycles, while persistent agents require ongoing OS and toolchain maintenance
    • cPersistent agents guarantee reproducible builds because they reuse warmed dependency and compiler caches across jobs
    • dEphemeral agents always deliver faster builds and lower compute costs than persistent agents
    Show the answer

    Answer: b · Ephemeral agents reduce security patching burden through short lifecycles, while persistent agents require ongoing OS and toolchain maintenance

    Ephemeral agents are short-lived, which minimizes patching and drift, whereas persistent agents accumulate state and need active maintenance. Distractor A is wrong because ephemeral agents can suffer from cold-start latency and repeated image pulls, and persistent agents can be more cost-effective when heavily utilized.

    Read the full bite: Compare ephemeral container agents versus persistent build agents

21. Question 21 of 30

    Which approach best balances speed and reliability when building a multi-arch CI pipeline for a compiled microservice targeting amd64 and arm64?

    • aRun all builds on x86_64 runners using QEMU emulation and a shared global cache
    • bSplit into separate repositories per architecture with matching long-lived branches
    • cUse native runners for heavy builds, architecture-scoped remote caches, and manifest lists for distribution
    • dCross-compile on x86_64 for speed and rely on emulation for all architecture-specific tests
    Show the answer

    Answer: c · Use native runners for heavy builds, architecture-scoped remote caches, and manifest lists for distribution

    The correct answer combines native runners for performance, architecture-scoped caches to prevent cross-arch poisoning, and manifest lists for clean distribution. Option A is tempting because centralizing on x86_64 seems simpler, but the card warns this causes a 5-10x QEMU slowdown and risks cache misses on one architecture invalidating another.

    Read the full bite: How would you design a multi-arch build process and anticipate challenges?

22. Question 22 of 30

    When integrating artifact signing into CI/CD, what is the primary security reason to move signing operations from the build runner to a remote KMS or HSM?

    • aTo ensure the private key never touches disk on ephemeral compute treated as untrusted
    • bTo avoid the operational burden of rotating short-lived signing certificates
    • cTo eliminate the need for signature verification at the deployment gate
    • dTo guarantee the artifact was built from an approved source code branch
    Show the answer

    Answer: a · To ensure the private key never touches disk on ephemeral compute treated as untrusted

    The card treats build runners as untrusted ephemeral infrastructure, so keeping the private key on a remote KMS or HSM prevents exfiltration if the runner is compromised. Option C is tempting but wrong because signature verification at deploy time must remain a hard gate regardless of how signing is performed.

    Read the full bite: How would you integrate artifact signing into CI/CD and secure the keys?

23. Question 23 of 30

    What is the key difference between a quality gate and running tests in a CI pipeline?

    • aA quality gate runs unit tests and linters automatically on every commit.
    • bA quality gate enforces metric thresholds that block merges or deployments when failed.
    • cA quality gate provides warnings about code style but never stops the pipeline.
    • dA quality gate generates test data for developers to review later.
    Show the answer

    Answer: b · A quality gate enforces metric thresholds that block merges or deployments when failed.

    A quality gate is a policy layer that enforces metric thresholds to block pipeline progression or merges, whereas merely running tests or linting only generates data without enforcing release readiness. The tempting distractor confuses executing checks with the policy decision that acts on their results.

    Read the full bite: What is a CI/CD quality gate? Give a simple example.

24. Question 24 of 30

    Why are unit tests placed in the build stage and integration tests in a later CI stage?

    • aUnit tests need real databases and message queues to validate wiring
    • bUnit tests are fast and isolated, while integration tests require real infrastructure and are slower
    • cBoth test types have similar speed and infrastructure cost, so stage placement is arbitrary
    • dIntegration tests check isolated functions with mocked dependencies and belong in the build stage
    Show the answer

    Answer: b · Unit tests are fast and isolated, while integration tests require real infrastructure and are slower

    Unit tests are fast and isolated with mocks, making them ideal for the build stage, while integration tests verify real wiring and need provisioned infrastructure, so they run later. Distractor B swaps the two definitions, which is a common misconception when candidates only memorize names without understanding the speed and isolation differences.

    Read the full bite: Difference between unit and integration tests and CI pipeline placement

25. Question 25 of 30

    Which approach reliably automates blocking a merge when a pull request causes total project coverage to drop by more than two percentage points?

    • aUse a custom shell script in CI to diff two coverage reports locally and fail the build if the drop exceeds 2%
    • bGenerate a coverage report in CI, upload it to Codecov, set the project status threshold to 2 in codecov.yml, and require the Codecov project status in branch protection
    • cPost coverage results as PR comments and rely on reviewers to block the merge manually if the drop exceeds 2%
    • dUpload coverage to Codecov, set a patch coverage target of 2% in codecov.yml, and require the Codecov patch status in branch protection
    Show the answer

    Answer: b · Generate a coverage report in CI, upload it to Codecov, set the project status threshold to 2 in codecov.yml, and require the Codecov project status in branch protection

    This option correctly combines coverage artifact generation, Codecov upload, a project status threshold of 2, and branch protection enforcement. Option D is tempting because it uses the same tools, but patch coverage only measures lines changed in the PR rather than the overall project drop.

    Read the full bite: How would you block merges when PR coverage drops 2%?

26. Question 26 of 30

    When first adding SAST to an existing CI pipeline, which rollout strategy best prevents alert fatigue while still shifting security left?

    • aRun SAST only on the main branch during nightly builds to keep merge request pipelines fast, reviewing findings before the next release
    • bStart in audit-only mode, tune rulesets to suppress false positives, and introduce merge-blocking gates for high and critical findings only after a calibration period
    • cBlock all merge requests on any SAST warning from day one, then gradually relax rules as developers request exceptions
    • dRequire the security team to manually triage every SAST finding in merge requests before developers can merge code
    Show the answer

    Answer: b · Start in audit-only mode, tune rulesets to suppress false positives, and introduce merge-blocking gates for high and critical findings only after a calibration period

    Starting in audit-only mode lets the team measure true positive rates and tune out noise before enforcing anything, which builds trust and avoids the alert fatigue that comes from blocking merges prematurely. Option C is a common trap because zero-tolerance blocking on day one creates toil and incentivizes developers to bypass the gate entirely.

    Read the full bite: How would you integrate SAST into CI without alert fatigue?

27. Question 27 of 30

    In an automated rollback pipeline triggered by a failed canary smoke test, which step must occur before redeploying the last known good release?

    • aPage the on-call engineer and wait for manual approval to proceed
    • bRun smoke tests against the previous release to confirm it is still healthy
    • cShift traffic back to the stable baseline and freeze the canary progression
    • dMutate the failed canary containers in place to patch the failing test
    Show the answer

    Answer: c · Shift traffic back to the stable baseline and freeze the canary progression

    The card states that traffic isolation—freezing the canary and shifting traffic to the stable baseline—must happen before any rollback begins to minimize blast radius. Running health checks against the previous release is part of post-redeploy verification, while manual approval or in-place patches break the automated safety contract.

    Read the full bite: Smoke test fails after canary deployment. Design the automated rollback.

28. Question 28 of 30

    Which strategy best balances immediate pipeline unblocking with sustainable reduction of E2E flakiness at scale?

    • aTreat flakiness as purely an infrastructure issue and upgrade CI hardware to eliminate variance
    • bBaseline flakiness rates, auto-quarantine chronic offenders from presubmit, and fix root causes like concurrency
    • cAutomatically retry every failed test up to five times before marking the build failed
    • dRequire developers to manually rerun the pipeline and triage failures before every merge
    Show the answer

    Answer: b · Baseline flakiness rates, auto-quarantine chronic offenders from presubmit, and fix root causes like concurrency

    Baselining metrics and quarantining chronic offenders targets root causes while protecting presubmit integrity. Relying solely on retries masks flakiness, delays detection of real breakages, and never reduces the overall flakiness rate.

    Read the full bite: How would you diagnose, report, and mitigate E2E flakiness at scale?

29. Question 29 of 30

    While developing on a feature branch, a team consumes an internal library that receives multiple daily updates. Which versioning strategy is most appropriate?

    • aUse a RELEASE version because Maven automatically re-downloads it on every build to fetch the latest changes
    • bUse a SNAPSHOT version because it allows frequent updates without cutting formal releases
    • cUse a SNAPSHOT version because it is immutable and guarantees bitwise reproducibility
    • dUse a RELEASE version and manually edit the version number in the POM for each daily update
    Show the answer

    Answer: b · Use a SNAPSHOT version because it allows frequent updates without cutting formal releases

    SNAPSHOT versions are mutable placeholders intended for feature branches and rapid iteration, allowing teams to share incremental builds without creating multiple immutable releases. Option A is tempting but wrong because RELEASE versions are immutable and never overwritten, so Maven does not re-download them to fetch changes.

    Read the full bite: SNAPSHOT and RELEASE versions: differences and appropriate use

30. Question 30 of 30

    In a hybrid Docker tagging strategy, what distinguishes the role of a Git SHA tag from a SemVer tag at production deployment time?

    • aThe Git SHA tag is safe to use as a rolling production target, while SemVer tags must be pinned to prevent drift.
    • bThe Git SHA tag is applied only after promotion gates pass, whereas SemVer tags are generated automatically on every CI build.
    • cThe Git SHA tag serves as a mutable alias for changelog consumers, while SemVer acts as the immutable canonical reference.
    • dThe Git SHA tag provides an immutable source-to-artifact mapping used in deployment manifests, while SemVer offers human-readable labels for promoted releases.
    Show the answer

    Answer: d · The Git SHA tag provides an immutable source-to-artifact mapping used in deployment manifests, while SemVer offers human-readable labels for promoted releases.

    Git SHA tags are immutable pointers created on every build to provide exact source-to-artifact traceability in manifests, while SemVer tags are human-readable aliases added only to promoted releases. Distractor C reverses this workflow: SHA tags are generated automatically per build, and SemVer is reserved for promoted images.

    Read the full bite: How do you version Docker images: Git SHA or SemVer?