Top 30 Intermediate 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 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

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

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

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

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

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

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

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

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

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

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

12. Question 12 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%?

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

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

15. Question 15 of 30

    Which capability best distinguishes a proxy repository from a simple file mirror?

    • aIt retains every artifact indefinitely without requiring cleanup or invalidation policies.
    • bIt caches metadata and checksums while enforcing policies at the network edge.
    • cIt serves as a writable location where internal teams publish and share internal artifacts.
    • dIt reduces external bandwidth by caching large binary files on the local network.
    Show the answer

    Answer: b · It caches metadata and checksums while enforcing policies at the network edge.

    A proxy repository is semantically aware: it caches metadata files and checksums, not just binaries, and enforces security policies before artifacts enter the network. Bandwidth reduction is a side benefit that a simple mirror could also provide, but it would lack the metadata handling and edge policy enforcement that make a proxy repository critical for supply-chain resilience.

    Read the full bite: Explain proxy repositories in artifact managers and the problems they solve

16. Question 16 of 30

    When promoting a tested JAR or image to production, which approach follows immutable artifact discipline?

    • aCopy the exact binary or retag the immutable digest without rebuilding.
    • bInject production configs and rebuild for the release repository.
    • cRebuild from cache using the same source to preserve tested bits.
    • dRebuild it with a production profile to guarantee a clean artifact.
    Show the answer

    Answer: a · Copy the exact binary or retag the immutable digest without rebuilding.

    Copying or retagging the exact artifact guarantees that production receives the identical bits validated in staging, whereas rebuilding from cache is risky because base images, package indexes, or transitive dependencies may have drifted.

    Read the full bite: Promote an artifact from staging to release without rebuilding it

17. Question 17 of 30

    Which approach to sharing CI/CD logic best preserves team autonomy while following DRY principles in a PaC setup?

    • aImport shared scripts unversioned from a main branch so fixes apply globally
    • bBuild versioned, parameterized units that teams compose into their own pipelines
    • cCopy common steps into each repository and customize them locally
    • dForce all teams to inherit from one global pipeline definition
    Show the answer

    Answer: b · Build versioned, parameterized units that teams compose into their own pipelines

    Versioned, parameterized units let teams reuse logic while controlling when they adopt changes, preserving independent release cadences. A single global pipeline (D) forces lockstep deployments and creates bottlenecks, while unversioned imports (A) risk breaking consumers unexpectedly.

    Read the full bite: How would you reuse pipeline steps across projects using PaC principles?

18. Question 18 of 30

    Which approach lets tests run on every branch while gating deploy to main only?

    • aConfigure an environment protection rule limited to main on the deploy job
    • bAdd if: github.ref == 'refs/heads/main' to the deploy job
    • cSet the workflow trigger to on.push.branches: main
    • dUse a shell if statement inside the deploy job to check the branch
    Show the answer

    Answer: b · Add if: github.ref == 'refs/heads/main' to the deploy job

    A job-level if condition is a native runtime conditional that keeps the test job in the DAG for all branches while skipping deploy when not on main. Using on.push.branches: main is a trigger filter that suppresses the entire workflow for other branches, so tests would never run there.

    Read the full bite: How would you implement conditional logic in a pipeline?

19. Question 19 of 30

    When converting a linear Jenkinsfile into a concurrent Declarative Pipeline, which practice best distributes workload without breaking dependencies?

    • aMap which stages are independent, wrap them in a parallel block with stage-level agents, and keep the Jenkinsfile under version control.
    • bWrap every post-build stage in a matrix block so each task runs concurrently across multiple browser versions.
    • cExtract each independent stage into its own standalone Jenkins job and use the build step to trigger them in parallel.
    • dPlace all test and scan stages into a parallel block and rely on the top-level agent to provision enough executors.
    Show the answer

    Answer: a · Map which stages are independent, wrap them in a parallel block with stage-level agents, and keep the Jenkinsfile under version control.

    Grouping only independent stages in a Declarative parallel block with stage-level agents spreads work across nodes while preserving required ordering for stages like compile or package. Relying on a top-level agent alone is wrong because parallel branches can still contend on a single executor without explicit per-stage agent allocation.

    Read the full bite: How would you use PaC to introduce pipeline parallelism?

20. Question 20 of 30

    When implementing a manual approval gate for production in pipeline-as-code, which approach best satisfies governance and auditability requirements?

    • aHave the pipeline send an email to the release manager and wait for a reply containing the word APPROVE before continuing to the production stage.
    • bConfigure a manual approval gate in the pipeline code, require approval from any team member with repository write access, and retain standard pipeline run logs for thirty days.
    • cDefine the approval gate in code using protected environment reviewers, enforce that the approver belongs to a separate RBAC group, set a timeout with re-evaluation, and store immutable audit logs outside the pipeline workspace.
    • dAllow the deploying engineer to obtain verbal approval from an on-call manager, then manually trigger the production stage from their local workstation using personal credentials.
    Show the answer

    Answer: c · Define the approval gate in code using protected environment reviewers, enforce that the approver belongs to a separate RBAC group, set a timeout with re-evaluation, and store immutable audit logs outside the pipeline workspace.

    The correct answer captures the core governance pattern: the gate is defined in code, bound to least-privilege identity with separation of duties, bounded by timeouts and re-evaluation, and backed by immutable external audit trails. Option B is tempting because it mentions pipeline code and logs, but it fails to restrict approvers to a specific RBAC group and relies on standard pipeline logs rather than immutable external storage, missing non-repudiation requirements.

    Read the full bite: Implement a manual approval gate for production deployment in pipeline-as-code

21. Question 21 of 30

    When configuring Terraform for an RDS database, which approach best limits secret exposure across version history and state files?

    • aStore the master password in AWS Secrets Manager with rotation enabled, reference the ARN in Terraform, and use an encrypted remote state backend
    • bEncrypt the master password with git-crypt and commit it to the same repository as the Terraform code
    • cPass the master password as an environment variable to the Terraform apply step
    • dStore the master password in terraform.tfvars inside a private Git repository
    Show the answer

    Answer: a · Store the master password in AWS Secrets Manager with rotation enabled, reference the ARN in Terraform, and use an encrypted remote state backend

    AWS Secrets Manager keeps the actual value out of code and enables automatic rotation and fine-grained access control, while an encrypted remote state backend prevents plaintext storage in state files. Passing the password via an environment variable is a common shortcut, but environment variables leak in process listings, crash reports, and potentially logs.

    Read the full bite: How do you manage secrets within IaC configurations?

22. Question 22 of 30

    When migrating a team from local to remote state, which requirement is most important to prevent corrupted infrastructure mappings?

    • aRestricting IAM access so only senior engineers can approve infrastructure changes.
    • bEnabling state file encryption at rest to protect sensitive resource attributes.
    • cEnabling versioning on the state bucket to reduce storage costs of old state files.
    • dConfiguring a remote backend with state locking to serialize concurrent plan and apply operations.
    Show the answer

    Answer: d · Configuring a remote backend with state locking to serialize concurrent plan and apply operations.

    State locking is the only mechanism that prevents race conditions when multiple engineers run apply simultaneously, which would otherwise overwrite resource mappings and corrupt state. Encryption, versioning, and IAM restrictions are important security and recovery measures, but none of them block concurrent modifications.

    Read the full bite: Explain Terraform state, why managing it is critical, and team best practices

23. Question 23 of 30

    An engineering team wants to spin up isolated test environments for every feature branch automatically. Which design best prevents cost leakage and cross-contamination while keeping environments truly ephemeral?

    • aUse dynamic branch-based naming with automatic stop jobs and TTL policies to destroy resources after merge
    • bCreate a persistent environment for each branch on first push and keep it running until the next release
    • cShare a single database and storage backend across all branch environments to reduce provisioning overhead
    • dHave developers clean up their own environments via a documented runbook triggered after pull request merge
    Show the answer

    Answer: a · Use dynamic branch-based naming with automatic stop jobs and TTL policies to destroy resources after merge

    Dynamic naming paired with automatic stop jobs or TTL policies guarantees isolated resources are destroyed when branches merge, preventing cost leakage. Persistent environments, manual runbooks, and shared backends are common anti-patterns that cause resource sprawl or cross-contamination.

    Read the full bite: Design a CI/CD pipeline for ephemeral feature branch environments

24. Question 24 of 30

    When a live production resource drifts from its approved Terraform definition, which response best reflects mature IaC governance?

    • aReplace the resource through an automated pipeline using the approved definition
    • bPerform root cause analysis without reverting the change to avoid disruption
    • cDocument the variance and schedule a quarterly manual alignment review
    • dUpdate the Terraform code to match the current resource and apply the change
    Show the answer

    Answer: a · Replace the resource through an automated pipeline using the approved definition

    Replacing the resource through an automated pipeline enforces immutable redeployment and treats the IaC repository as the single source of truth. Option D is a common anti-pattern because updating code to match drift validates unauthorized live changes instead of reverting them.

    Read the full bite: Define configuration drift in IaC. How do you detect and remediate it?

25. Question 25 of 30

    Which approach best implements defense-in-depth for delivering database credentials to a Kubernetes application through CI/CD?

    • aPlace the password in a ConfigMap, expose it as an environment variable, and rely on Kubernetes default secret encryption
    • bStore credentials in a private Git repo, sync them with cluster-admin privileges, and mount them as a volume
    • cFetch from an external secret manager via an operator, mount as a read-only volume, enforce least-privilege RBAC, and encrypt etcd at rest
    • dBuild the password into the container image and inject it via an environment variable at runtime
    Show the answer

    Answer: c · Fetch from an external secret manager via an operator, mount as a read-only volume, enforce least-privilege RBAC, and encrypt etcd at rest

    This combines external secret management, volume mount isolation, least-privilege RBAC, and etcd encryption as the card recommends. Option A is tempting because it uses native Kubernetes objects, but ConfigMaps lack confidentiality design and default etcd encryption is not enabled without an EncryptionConfiguration.

    Read the full bite: Describe secure secret injection into Kubernetes containers during CI/CD

26. Question 26 of 30

    Which pattern best solves the secret zero problem for an app retrieving secrets from Vault in a Kubernetes cluster?

    • aUse a projected service account token to authenticate to Vault via the Kubernetes auth method, obtaining a short-lived token through an init container or sidecar
    • bDistribute a unique TLS client certificate to each pod via a config map and have Vault verify the certificate subject for every secret request
    • cEmbed a wrapped Vault token directly into the container image during the CI build so the app can unwrap it at runtime
    • dStore a long-lived Vault root token in a Kubernetes Secret mounted as an environment variable for the app to use at startup
    Show the answer

    Answer: a · Use a projected service account token to authenticate to Vault via the Kubernetes auth method, obtaining a short-lived token through an init container or sidecar

    Projected service account tokens let Vault verify identity through the Kubernetes API, yielding short-lived tokens without hardcoded credentials. Storing a root token in a Kubernetes Secret and mounting it as an environment variable merely shifts the secret zero problem one layer deeper and lacks platform attestation.

    Read the full bite: How does your app authenticate with secrets management and solve secret zero?

27. Question 27 of 30

    A team needs continuous drift detection for Kubernetes and configuration management for VMs and network gear with immutable audit trails. Which approach fits best?

    • aUse Kustomize overlays for all infrastructure since GitOps eliminates all drift across VMs and external cloud state.
    • bUse Ansible for both Kubernetes and network gear to avoid brittle Kustomize inheritance hierarchies beyond three or four environments.
    • cUse Ansible for everything because it provides native continuous drift reconciliation and works agentlessly across all infrastructure types.
    • dUse GitOps with Kustomize for Kubernetes and Ansible for VMs and network gear.
    Show the answer

    Answer: d · Use GitOps with Kustomize for Kubernetes and Ansible for VMs and network gear.

    The card states that hybrid VM and container estates often need both tools in tandem, using GitOps for Kubernetes drift detection and Ansible for diverse infrastructure. Option B is tempting because Kustomize overlays do become brittle beyond three to four environments, but abandoning GitOps sacrifices the required continuous drift detection and immutable audit trails for Kubernetes.

    Read the full bite: Compare GitOps and Kustomize vs Ansible for environment configs

28. Question 28 of 30

    When a readiness probe fails on a running Pod, what is the immediate consequence?

    • aThe container keeps running, but its IP is removed from matching Service endpoints.
    • bThe kubelet restarts the container according to the Pod's restartPolicy.
    • cThe Pod is evicted and rescheduled onto a different node.
    • dThe container process is killed while the Pod IP stays in Service endpoints.
    Show the answer

    Answer: a · The container keeps running, but its IP is removed from matching Service endpoints.

    Readiness failure causes the endpoint controller to remove the Pod's IP from Service endpoints, stopping new traffic while the container continues running. Option B is wrong because restarting the container is the kubelet's response to a liveness failure, not readiness.

    Read the full bite: What are liveness and readiness probes, and what happens when each fails?

29. Question 29 of 30

    When deploying a three-replica Apache Kafka cluster in Kubernetes, why is a StatefulSet the appropriate abstraction rather than a Deployment?

    • aStatefulSets use a single shared PersistentVolumeClaim template so every replica accesses the same data directory
    • bStatefulSets provide each broker with a stable ordinal hostname and a dedicated persistent volume that remains bound to that specific pod identity across rescheduling
    • cStatefulSets create pods with random hashed names to ensure no single broker becomes a permanent bottleneck
    • dStatefulSets guarantee automatic strong consistency and consensus management for the broker cluster
    Show the answer

    Answer: b · StatefulSets provide each broker with a stable ordinal hostname and a dedicated persistent volume that remains bound to that specific pod identity across rescheduling

    A StatefulSet gives each Kafka broker a stable ordinal hostname and a dedicated PVC that follows the pod across rescheduling, which is required to preserve broker IDs and log segments. The most tempting distractor claims strong consistency guarantees, but the card explicitly notes that StatefulSets only provide stable infrastructure; the application itself must still handle consensus.

    Read the full bite: Describe the difference between a Deployment and a StatefulSet

30. Question 30 of 30

    Why should a CI/CD pipeline update the Deployment spec with a unique image tag rather than repushing the same :latest tag?

    • aKubernetes automatically detects when the underlying :latest image changes and redeploys pods
    • bUpdating the spec with a unique tag triggers a controlled rollout and ensures reproducible rollbacks
    • cUnique tags prevent the container runtime from caching images and causing stale layer issues
    • dSetting imagePullPolicy to Always with :latest guarantees all nodes run identical images
    Show the answer

    Answer: b · Updating the spec with a unique tag triggers a controlled rollout and ensures reproducible rollbacks

    Updating the spec with an immutable tag changes the pod template, driving a controlled rolling update and enabling deterministic rollbacks. The tempting idea that imagePullPolicy: Always fixes :latest is wrong because the tag is mutable, so nodes pulling at different times can still end up running different images.

    Read the full bite: How ensure Kubernetes pulls correct new image and why avoid :latest?