Top 30 Easy CI/CD & Automation Interview Questions and Answers for Freshers

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

   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

4. Question 4 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.

5. Question 5 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?

6. Question 6 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.

7. Question 7 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

8. Question 8 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

9. Question 9 of 30

   Which statement best explains why Pipeline as Code reduces operational risk compared to GUI-based configuration?

   • aIt allows one-off prototype jobs to be created more quickly without committing files
   • bIt lets teams edit the pipeline through the web UI while still tracking changes in the job history
   • cIt subjects pipeline changes to version control, peer review, and a durable audit trail
   • dIt automates application deployments without requiring the pipeline to be stored in Git
   Show the answer

   Answer: c · It subjects pipeline changes to version control, peer review, and a durable audit trail

   Pipeline as Code reduces risk by treating the pipeline definition as versioned code, enabling peer review, branch automation, and a full audit trail. Option D is tempting because automation is a related concept, but PaC's core value depends on storing the pipeline in source control, not merely automating deployments.

   Read the full bite: What is Pipeline as Code and its benefits over GUI configuration?

10. Question 10 of 30

    When starting a new project with typical build, test, and deploy stages, why should Declarative Pipeline be the default choice?

    • aIt standardizes structure and readability while still permitting Groovy inside a script block.
    • bIt is required to use built-in steps like sh and docker.build.
    • cIt offers unrestricted Groovy flow control for complex logic at the top level.
    • dIt removes all code-size limits that restrict pipeline growth.
    Show the answer

    Answer: a · It standardizes structure and readability while still permitting Groovy inside a script block.

    Declarative is the recommended default because its enforced structure improves team readability and onboarding, and it still allows Groovy inside a script block. Option C actually describes Scripted Pipeline, which sacrifices those guardrails and is unnecessary for typical CI/CD workflows.

    Read the full bite: Declarative vs scripted pipeline syntax: when to choose each?

11. Question 11 of 30

    Which strategy best follows modern secrets management for a sensitive token needed by a committed CI/CD pipeline?

    • aFetch the token at runtime from an external secrets manager using the platform's native integration
    • bStore the token as a masked, hidden, and protected CI/CD variable configured at the project level
    • cCommit the token encrypted with AES-256 to the repository so the pipeline can decrypt it during execution
    • dPass the token via typed CI/CD inputs to ensure type-safe validation and scoped availability
    Show the answer

    Answer: a · Fetch the token at runtime from an external secrets manager using the platform's native integration

    The correct answer is C because external secrets managers inject ephemeral credentials at runtime without persisting secrets in version control or project settings. Option B is tempting but wrong because CI/CD variables live in project settings where they can be overridden or exposed in logs, making them a less secure fallback rather than the best practice.

    Read the full bite: How should you manage sensitive data in a committed pipeline file?

12. Question 12 of 30

    Which practice best describes how Infrastructure as Code prevents configuration drift across CI/CD environments?

    • aTeams maintain detailed runbooks that document every manual change made to production servers
    • bDeployment speed is increased by automating infrastructure changes without defining desired state
    • cOperators run standardized shell scripts to configure each server identically
    • dEnvironments are defined by versioned declarative files that specify the desired state and can be recreated on demand
    Show the answer

    Answer: d · Environments are defined by versioned declarative files that specify the desired state and can be recreated on demand

    Declarative, versioned definitions ensure every environment matches the desired state and can be reproduced identically, which stops drift. Standardized shell scripts are imperative and still risk configuration drift because they depend on the server's starting state and do not enforce a unified model.

    Read the full bite: What is IaC and its CI/CD benefits over manual provisioning?

13. Question 13 of 30

    You are choosing between Terraform and Ansible for provisioning AWS VPCs and installing application packages. What is the primary decision factor?

    • aTerraform is imperative because it uses provisioners, while Ansible is declarative because it uses modules
    • bAnsible is declarative because its playbooks are idempotent, while Terraform is imperative because it executes ordered resources
    • cBoth are declarative, but Terraform is preferred because it detects drift automatically
    • dTerraform is declarative and tracks state for infrastructure, while Ansible is imperative for procedural tasks
    Show the answer

    Answer: d · Terraform is declarative and tracks state for infrastructure, while Ansible is imperative for procedural tasks

    Terraform defines the desired end state of infrastructure and relies on a state engine for reconciliation, while Ansible executes ordered commands for procedural tasks. The distractor claiming Ansible is declarative simply because it is idempotent confuses a property of safe repetition with the desired-state paradigm, which is a common misconception.

    Read the full bite: Explain the difference between declarative and imperative IaC.

14. Question 14 of 30

    A developer runs terraform plan in a CLI-driven HCP Terraform workspace. What occurs during this step?

    • aThe workspace locks state and provisions the proposed resources immediately after policy checks pass
    • bA remote speculative plan previews changes, validates against policies, and leaves infrastructure unchanged
    • cAll workspace variables and sensitive values are downloaded to the developer's local machine for execution
    • dThe configuration is automatically committed to version control before the remote run begins
    Show the answer

    Answer: b · A remote speculative plan previews changes, validates against policies, and leaves infrastructure unchanged

    terraform plan initiates a remote speculative run that shows proposed changes and checks policies without altering infrastructure. Distractor A is wrong because provisioning and state locking happen during terraform apply, not during the speculative plan phase.

    Read the full bite: Describe the Terraform workflow from code to live

15. Question 15 of 30

    When configuring a .NET app for multiple environments, which approach best prevents connection string secrets from being exposed?

    • aPlace the connection string in a Universal Data Link file on the server and reference it from the application configuration
    • bInject values via environment variables or a secret store at runtime, and prefer authentication methods that eliminate passwords from the string
    • cStore environment-specific connection strings in appsettings files and check them into source control so they deploy with the application
    • dUse C# preprocessor directives to select the correct hardcoded string at compile time based on the target environment
    Show the answer

    Answer: b · Inject values via environment variables or a secret store at runtime, and prefer authentication methods that eliminate passwords from the string

    Injecting via environment variables or a secret store keeps secrets out of source control and compiled binaries, while managed identities remove passwords entirely. Preprocessor directives are a tempting distractor because they appear to separate environments but still embed secrets in the assembly that can be extracted with ILDASM.

    Read the full bite: How do you manage environment-specific connection strings and why is hardcoding bad?

16. Question 16 of 30

    Which approach best keeps database credentials out of Git while supporting local development?

    • aEncode the credentials with base64 and store them in a committed config file
    • bCommit a template file and manually replace values before each deployment
    • cStore credentials in a committed file and delete it in a later commit if exposed
    • dUse a .env file listed in .gitignore and read via environment variables
    Show the answer

    Answer: d · Use a .env file listed in .gitignore and read via environment variables

    A gitignored .env file keeps secrets out of the repository while the app reads them at runtime via environment variables. Deleting a committed file later is insufficient because Git history is immutable and distributed, so the secret remains in every clone and fork.

    Read the full bite: Why avoid committing secrets to Git, and secure local alternatives?

17. Question 17 of 30

    A team following Twelve-Factor Factor III stores configuration in environment variables. What operational benefit does this provide for CI/CD and scalability?

    • aOne build artifact can be promoted across environments and new instances start with the correct context immediately.
    • bThe application can bundle all settings inside the deployed artifact to remain self-contained.
    • cEach environment can use its own Git branch to manage configuration independently.
    • dOnly secrets are kept outside source code while non-secret settings remain hard-coded.
    Show the answer

    Answer: a · One build artifact can be promoted across environments and new instances start with the correct context immediately.

    Storing config in environment variables keeps the codebase identical across stages, enabling a single artifact to be promoted through CI/CD and allowing new instances to read the correct settings at startup for horizontal scaling. The distractor about keeping only secrets in env vars is wrong because Factor III applies to all deployment-specific configuration, not just sensitive data.

    Read the full bite: What is Twelve-Factor's config recommendation for CI/CD and scalability?

18. Question 18 of 30

    In a production Dockerfile, what is the primary purpose of splitting the build into multiple stages?

    • aTo keep build dependencies and compilers out of the final deployed image
    • bTo run build and runtime processes in parallel within one container
    • cTo increase the total number of layers available for build caching
    • dTo ensure build tools like GCC remain available in the final image for debugging
    Show the answer

    Answer: a · To keep build dependencies and compilers out of the final deployed image

    Multi-stage builds isolate compilation in a builder stage and copy only runtime artifacts to the final image, eliminating compilers and dev tools that increase size and attack surface. Option D describes a common anti-pattern: keeping build tools in production for debugging, which defeats the security and size benefits of multi-stage builds.

    Read the full bite: Walk me through a production-ready Dockerfile for a web app

19. Question 19 of 30

    In Kubernetes, which correctly describes how external HTTP traffic reaches Pods when using an Ingress?

    • aIngress sends traffic directly to Pod IPs, skipping the Service layer
    • bIngress routes to a Service, which load-balances across Pods
    • cAn Ingress resource alone handles both external routing and internal Pod load balancing
    • dA Service handles external HTTP routing before passing requests to an Ingress
    Show the answer

    Answer: b · Ingress routes to a Service, which load-balances across Pods

    External traffic first hits the Ingress, which performs Layer 7 routing to a Service; the Service then load-balances at Layer 4 across Pods. Option A is tempting but wrong because Ingress does not bypass the Service to reach Pods directly.

    Read the full bite: What is the difference between a Service and an Ingress?

20. Question 20 of 30

    You need to deploy a new release without increasing baseline compute capacity, and you can tolerate old and new versions coexisting briefly. Which strategy fits these constraints?

    • aBlue/green, because it reuses the existing infrastructure to keep costs unchanged
    • bRolling, because it replaces instances gradually within the current environment
    • cRolling, because it creates a full duplicate stack for validation before cutover
    • dBlue/green, because it routes traffic to only one environment at a time
    Show the answer

    Answer: b · Rolling, because it replaces instances gradually within the current environment

    Rolling deployment updates instances gradually within the existing environment, keeping infrastructure costs at baseline while old and new versions temporarily coexist. Option A is a tempting misconception: blue/green requires provisioning a duplicate stack, so it doubles capacity during the cutover rather than reusing existing infrastructure.

    Read the full bite: Rolling vs blue/green deployments: differences and trade-offs

21. Question 21 of 30

    When mitigating deployment risk, how does a canary release differ from a rolling update?

    • aCanary releases route a small subset of users to the new version first for early risk detection, while rolling updates replace instances without deliberately segmenting traffic.
    • bCanary releases replace instances in-place across the fleet gradually, while rolling updates route a small user subset to the new version first.
    • cThey are essentially the same strategy with different names, differing only in speed and not in traffic routing.
    • dCanary releases are long-term feature experiments for statistical significance, whereas rolling updates are used for quick regression detection during deployment.
    Show the answer

    Answer: a · Canary releases route a small subset of users to the new version first for early risk detection, while rolling updates replace instances without deliberately segmenting traffic.

    Canary releases isolate risk by routing a limited user group to the new version before full rollout, whereas rolling updates replace instances across the fleet without deliberately segmenting traffic. Option B reverses these roles, which is a common misconception.

    Read the full bite: Explain canary releases and why choose them over rolling updates

22. Question 22 of 30

    Why does a breaking API change risk errors during a Kubernetes rolling update?

    • aOld and new pods coexist behind the Service, so traffic crosses incompatible versions.
    • bKubernetes terminates all old pods before any new pods start serving traffic.
    • cReadiness probes always detect breaking API changes and block new pods from the Service.
    • dThe Deployment controller automatically isolates traffic between different pod versions.
    Show the answer

    Answer: a · Old and new pods coexist behind the Service, so traffic crosses incompatible versions.

    During a rolling update, old and new pods run simultaneously behind the same Service, so a breaking API change causes cross-traffic failures like HTTP 500s. It is wrong to think Kubernetes drains all old pods first, because the rollout intentionally scales new pods up while old pods are still running and receiving traffic.

    Read the full bite: What problem can a breaking API change cause during a rolling update?

23. Question 23 of 30

    Where should SAST be placed in CI/CD to maximize shift-left value, and why?

    • aIt should run after deployment so it can analyze the running application using live traffic data
    • bIt should run only in nightly pipelines to avoid slowing down developer workflows with per-commit noise
    • cIt should run as a manual gate before production so security teams can triage every finding
    • dIt should run in the test stage on every commit because flaws are cheapest to fix while the code context is fresh
    Show the answer

    Answer: d · It should run in the test stage on every commit because flaws are cheapest to fix while the code context is fresh

    Running SAST in the test stage on every commit provides immediate feedback when the code context is fresh, making vulnerabilities cheapest to fix before they reach production. Option A is tempting because beginners often confuse static source-code analysis with dynamic runtime testing, but SAST does not require a deployed application.

    Read the full bite: What is SAST and which CI/CD stage integrates it best?

24. Question 24 of 30

    Which two automated layers provide the strongest defense against committing API keys to Git?

    • aRequiring signed commits and enforcing branch protection with mandatory pull request approvals
    • bManual code review of every diff and a developer checklist before pushing code
    • cRemoving the leaked secret file and running simple string matching during the CI pipeline
    • dClient-side pre-commit scanning that blocks local commits and server-side or CI pipeline scanning that rejects pushes or fails builds
    Show the answer

    Answer: d · Client-side pre-commit scanning that blocks local commits and server-side or CI pipeline scanning that rejects pushes or fails builds

    Option D is correct because it layers client-side pre-commit hooks that catch secrets before they leave the developer machine with server-side or CI scanning that acts as a second automated gate. Option C is tempting because it mentions CI scanning, but deleting the file does not remove the secret from Git history and simple string matching produces high false positives while missing novel secret formats.

    Read the full bite: Committed an API key to Git. Describe two automated CI/CD prevention methods.

25. Question 25 of 30

    A service shows normal CPU and memory after a deployment, but users report slow responses. Which principle of the Golden Signals does this best demonstrate?

    • aSaturation is identical to high CPU utilization
    • bTraffic spikes are the primary cause of latency regressions
    • cLatency should be averaged across all requests
    • dInfrastructure metrics can stay green while user experience degrades
    Show the answer

    Answer: d · Infrastructure metrics can stay green while user experience degrades

    The Golden Signals prioritize request-level user pain over machine metrics, so latency and errors can spike even when CPU and memory appear healthy. The saturation distractor is wrong because saturation means a resource is actively throttling work, not merely that CPU utilization is high.

    Read the full bite: What are the four Golden Signals for service health monitoring?

26. Question 26 of 30

    A developer manually scales a Deployment to seven replicas via kubectl, but Git declares three. What does the GitOps agent do on its next reconciliation?

    • aUpdate the Git repository to match the live seven-replica state
    • bDo nothing because the change did not originate from Git
    • cScale the Deployment back to three replicas to match Git
    • dWait for manual approval before making any changes
    Show the answer

    Answer: c · Scale the Deployment back to three replicas to match Git

    The GitOps agent continuously reconciles live cluster state against Git as the single source of truth, so it self-heals by scaling back to three. Distractor B is wrong because Git, not the live cluster, is the authoritative desired state, so the agent does not write drift back to the repository.

    Read the full bite: Explain GitOps and how an agent knows when to apply changes

27. Question 27 of 30

    You need to deploy a payment-processing bug fix that requires instant rollback capability if success rates drop. Which strategy and rationale fit best?

    • aCanary release, because it maintains two identical production environments so the old version remains fully warm
    • bBlue/green deployment, because it gradually routes five percent of real traffic to the new version while monitoring health metrics
    • cCanary release, because it limits the blast radius to a small cohort while providing sub-second rollback via shared infrastructure
    • dBlue/green deployment, because you can validate in the idle environment and swap all traffic instantly, reverting just as quickly if needed
    Show the answer

    Answer: d · Blue/green deployment, because you can validate in the idle environment and swap all traffic instantly, reverting just as quickly if needed

    The card explicitly pairs blue/green with scenarios requiring immediate full cutover and sub-second rollback, such as the payment bug example. Option C is tempting because it combines canary's limited blast radius with blue/green's rollback speed, but canary inherently requires more time to drain traffic during a rollback.

    Read the full bite: Blue/green vs canary release: differences and when to choose each.

28. Question 28 of 30

    After CI updates the image tag in the Git repository, how is the new version deployed in a GitOps workflow?

    • aThe CI pipeline pushes the update directly to the cluster using kubectl apply
    • bThe cluster watches the container registry and automatically rolls out the new image tag
    • cThe GitOps controller detects the manifest change and reconciles the cluster state to match Git
    • dA release engineer manually triggers a sync job to update the live deployment
    Show the answer

    Answer: c · The GitOps controller detects the manifest change and reconciles the cluster state to match Git

    In GitOps, the GitOps controller continuously compares the declarative desired state in Git with the live cluster state and automatically reconciles differences, so the cluster converges to what is defined in version control. The distractor describing CI pushing directly with kubectl apply describes a traditional push-based pipeline, which violates the GitOps principle of keeping cluster access out of the build stage and fails to use Git as the single source of truth.

    Read the full bite: Walk me through deploying a new version using a GitOps workflow

29. Question 29 of 30

    Which approach best represents the golden path for onboarding a new microservice to a self-service CI/CD platform?

    • aUsing a templated repository generator that references centrally maintained reusable pipeline modules
    • bHardcoding environment-specific secrets directly in the pipeline configuration for simplicity
    • cSubmitting a ticket for the platform team to manually create pipeline jobs and namespaces
    • dAllowing each team to design their own pipeline from scratch for maximum flexibility
    Show the answer

    Answer: a · Using a templated repository generator that references centrally maintained reusable pipeline modules

    The card emphasizes that self-service onboarding relies on templated repositories and reusable pipeline modules to minimize platform intervention while enforcing standards. A ticket-based workflow (option C) is explicitly flagged as a red flag because it creates manual bottlenecks and defeats the purpose of self-service.

    Read the full bite: Describe high-level steps to onboard a microservice via self-service CI/CD

30. Question 30 of 30

    Which approach best protects existing pipelines when releasing a breaking change to a shared CI action?

    • aOverwrite the existing major tag and publish a migration guide
    • bUpdate the floating major tag in place since semantic versioning signals the breaking change
    • cPush the change to the main branch and notify teams to update their workflows
    • dCut a new major version tag, leave old tags untouched, and support both during a deprecation window
    Show the answer

    Answer: d · Cut a new major version tag, leave old tags untouched, and support both during a deprecation window

    The card states that breaking changes require a new major version tag, immutable old tags, and a deprecation window for the previous version. Option A is tempting because it includes a migration guide, but overwriting an existing tag destroys reproducibility and instantly breaks all consuming pipelines.

    Read the full bite: How do you version shared CI steps and handle breaking changes?