Question 1

What is Cloud Build?

Accepted Answer

Cloud Build is GCP's serverless CI/CD execution service. A build is a sequence of steps, each running a container image with your source mounted, defined in a cloudbuild.yaml or a Dockerfile. It triggers on repository events, has no build servers to maintain, and integrates with IAM, Secret Manager, Artifact Registry and Cloud Deploy. The "every step is a container" model is the point to draw out: it means any tool can be a build step without installing anything on a shared agent, and steps are reproducible. That is a meaningful difference from a traditional agent-based CI system with drifting tool versions.

Question 2

How do build steps share data in Cloud Build?

Accepted Answer

All steps share the /workspace volume, which holds the checked-out source and persists across steps within a build. Anything written elsewhere in a step's container is lost when that step ends. Artifacts that must outlive the build go to Artifact Registry or Cloud Storage. The follow-up is step ordering and parallelism: steps run sequentially by default, and waitFor lets you express a dependency graph so independent steps run in parallel. Knowing waitFor is a good signal of having optimised a real pipeline.

Question 3

What are Cloud Build substitutions?

Accepted Answer

Substitutions are variables in the build configuration. Built-in ones include $PROJECT_ID, $BUILD_ID, $COMMIT_SHA, $SHORT_SHA, $BRANCH_NAME and $TAG_NAME. You can define user substitutions, which must be prefixed with an underscore, and pass values from the trigger or the command line. Tagging images with $SHORT_SHA rather than "latest" is the practice this enables and the one interviewers listen for, because an immutable, traceable tag is what makes rollback and provenance possible. "latest" in production is a well-known anti-pattern.

Question 4

What service account does Cloud Build run as and why does it matter?

Accepted Answer

By default, a Cloud Build service account with broad permissions in the project. It matters because that identity is what deploys your code, so it is a high-value target — a compromised repository or a malicious build step inherits its permissions. Best practice is a dedicated, least-privilege service account per pipeline and per environment. The escalation path to name is that a build with permission to deploy to production effectively grants production access to anyone who can merge a change to the build configuration. That is why build configuration changes should require review just like code.

Question 5

What is Artifact Registry and why did it replace Container Registry?

Accepted Answer

Artifact Registry stores container images and language packages — Maven, npm, Python, Go, Debian, RPM — in regional repositories with per-repository IAM, CMEK support, vulnerability scanning and remote and virtual repository types. Container Registry was a thin layer over Cloud Storage with only bucket-level access control. Per-repository IAM is the concrete improvement: separating one team's images from another's was awkward when access was really a bucket policy. Remote repositories, which proxy and cache Docker Hub or npm, are the other feature worth naming because they protect builds from upstream outages and rate limits.

Question 6

What is a remote repository in Artifact Registry?

Accepted Answer

A remote repository proxies an upstream public registry such as Docker Hub, Maven Central or PyPI, caching what you pull. That insulates builds from upstream rate limits and outages, gives you a record of exactly what was pulled, and lets scanning and policy apply to third-party artefacts. The supply-chain benefit is the strong argument: pulling directly from a public registry means an upstream compromise reaches production immediately, whereas a cached, scanned proxy gives you a control point. Docker Hub rate limits breaking builds is the practical trigger most teams hit first.

Question 7

What is Cloud Deploy?

Accepted Answer

Cloud Deploy is a managed continuous delivery service that models a delivery pipeline with ordered targets — dev, staging, production — and promotes a release through them. It supports approval gates, canary and blue-green strategies, automated rollback, and per-target verification jobs, with delivery metrics and audit history. The separation Cloud Deploy enforces is between build and deploy: Cloud Build produces an immutable artefact, Cloud Deploy promotes that same artefact through environments. Rebuilding per environment is the anti-pattern it removes, because you then deploy something you never tested.

Question 8

What deployment strategies would you use and when?

Accepted Answer

Rolling update for most stateless services — gradual replacement with maxSurge and maxUnavailable control. Blue-green when you need an instant, complete cutover and instant rollback, at the cost of double capacity. Canary when you want to limit exposure by sending a small traffic percentage to the new version and promoting on metrics. Feature flags to decouple deployment from release entirely. The feature-flag point is the one that elevates the answer: separating "the code is deployed" from "the feature is on" means a bad feature is switched off in seconds without a rollback. Naming the promotion criterion — error rate and latency versus the stable version — is what makes canary real rather than theatrical.

Question 9

How do you implement a canary deployment on Cloud Run?

Accepted Answer

Deploy the new revision with --no-traffic and a tag, giving it a testable URL with no production traffic. Smoke test it, then shift traffic in increments with update-traffic while watching error rate and latency. Rollback is shifting traffic back to the previous revision, which is still deployed and warm. The tagged-revision URL is the differentiating capability: you validate the exact artefact in the production environment with zero blast radius. Automating promotion on SLO metrics with Cloud Deploy turns the manual process into a repeatable one.

Question 10

What is GitOps and how would you implement it on GCP?

Accepted Answer

GitOps makes a Git repository the single source of truth for desired state, with an agent continuously reconciling the cluster to match it. On GCP that is Config Sync, part of Anthos Config Management, watching a repository and applying manifests to one or many GKE clusters, with Policy Controller enforcing guardrails. The properties to name are drift correction — a manual kubectl change is reverted automatically — and auditability, since every change is a reviewed commit. The trade-off is that emergency manual changes are undone unless you have a defined break-glass procedure, which is worth acknowledging.

Question 11

How do you manage secrets in a CI/CD pipeline on GCP?

Accepted Answer

Store them in Secret Manager and grant the build service account access to specific secrets, referencing them in the build configuration rather than as plain substitutions. Never commit secrets to the repository or pass them as build arguments that appear in image layers or logs. For external systems, prefer Workload Identity Federation over stored credentials. The Docker build-arg leak is the specific trap: values passed with --build-arg are visible in the image history, so a secret baked in that way is recoverable from the published image. Naming that failure is a strong practical signal.

Question 12

How do you authenticate GitHub Actions to GCP without a service-account key?

Accepted Answer

Workload Identity Federation: create a workload identity pool and an OIDC provider trusting GitHub's issuer, with attribute conditions restricting which repository and ref may authenticate, then let the workflow exchange its GitHub OIDC token for a short-lived GCP credential. The attribute condition is security-critical: without restricting on repository and ref, other repositories can obtain the credential. That exact misconfiguration has caused real production compromises, which is why interviewers ask specifically how the trust is scoped.

Question 13

What is a build trigger and what event types can start a build?

Accepted Answer

A trigger connects a repository event to a build configuration — push to a branch, a new tag, a pull request, or a manual or scheduled invocation. Triggers can filter by branch pattern and by changed file paths, which is how you avoid rebuilding the whole monorepo for a documentation change. Path filtering is the monorepo answer and the detail worth naming, because without it CI time grows until nobody trusts it. Pull-request triggers running tests before merge, and tag triggers producing release artefacts, is the standard two-trigger structure.

Question 14

How do you speed up a slow Cloud Build pipeline?

Accepted Answer

Use waitFor to parallelise independent steps; cache dependencies in Cloud Storage or use Kaniko or BuildKit layer caching; use a larger machine type for the build; split long test suites and run them in parallel; use path filters so only affected components build; and build a smaller image with multi-stage Dockerfiles. Dependency caching is usually the largest single win, because a fresh npm or Maven install dominates many builds. The trade-off to acknowledge is cache invalidation correctness — a stale cache producing a build that works locally and fails in production is worse than a slow build.

Question 15

What is a multi-stage Dockerfile and why does it matter for CI/CD?

Accepted Answer

A multi-stage build uses one stage with the full toolchain to compile and test, then copies only the resulting artefacts into a minimal runtime stage. The published image contains no compilers, build tools or source, so it is smaller, starts faster and has a much smaller vulnerability surface. The security angle is the strongest argument: a build-tool-laden image gives an attacker a compiler and package manager inside your production container. Distroless or minimal base images take that further, and naming them shows current practice.

Question 16

What is supply-chain security in a delivery pipeline and what does GCP provide?

Accepted Answer

It is assurance that what runs in production is what you intended, built from reviewed source by a trusted system. GCP provides Artifact Registry vulnerability scanning, Cloud Build provenance metadata attesting how an image was built, Binary Authorization to block unattested images at deploy, and Assured Open Source Software for vetted dependencies. The SLSA framework is the vocabulary to use, and the practical chain is: signed source, verified build, generated provenance, scanned artefact, attested deploy. Naming the break-glass path is important too, because an emergency deploy will eventually be needed and an undesigned bypass becomes permanent.

Question 17

What is Binary Authorization and how does it fit a pipeline?

Accepted Answer

It is an admission-time policy that only permits images carrying required attestations to run on GKE, Cloud Run or Anthos. The pipeline creates attestations after each gate — built by the trusted builder, passed vulnerability scan, approved by QA — and the policy requires them at deploy. The property that makes it valuable is that it enforces at deployment rather than at build, so an image pushed by any other route still cannot run. That closes the gap where a developer with registry write access could bypass CI entirely.

Question 18

How do you promote an artefact through environments without rebuilding?

Accepted Answer

Build once, tag with an immutable identifier such as the commit SHA and a digest, publish to a registry, and promote that exact digest through environments with environment-specific configuration injected at deploy time. Cloud Deploy models this as a release promoted through ordered targets. The reason rebuilding per environment is wrong is that the production artefact was then never tested — dependency resolution, base image updates and build-time differences can all change it. Insisting on build-once-deploy-many is a core delivery principle and interviewers listen for it.

Question 19

How do you manage environment-specific configuration?

Accepted Answer

Keep it out of the artefact. Inject it at deploy time through environment variables, Secret Manager references, Kubernetes ConfigMaps or a configuration service, with the values held in version-controlled, environment-specific files or in Terraform. The same image then runs in every environment. The failure this prevents is a per-environment image, which reintroduces the build-once problem. The related discipline is that adding a new configuration value should require a change in one reviewed place, not in three deployment scripts that drift.

Question 20

What tests would you run at which stage of a pipeline?

Accepted Answer

Unit tests and static analysis on every commit, fast enough to run in a minute or two. Integration tests against emulators or a test project after build. Contract tests between services. Smoke tests against the deployed artefact in staging. Then a canary in production with automated metric checks. Load and security scans on a slower cadence or before a release. The principle is fail fast and cheap: anything that can be caught in seconds should be, so slow tests run only on candidates that already passed. Naming production smoke tests and canary metric checks as part of testing — rather than treating testing as pre-deployment only — is the modern view.

Question 21

How do you handle database migrations in a CI/CD pipeline?

Accepted Answer

Run them as an explicit, versioned step with a migration tool, separately from the application deploy, and make every migration backwards-compatible with the currently running version using expand-and-contract. Deploy the migration first, then the code, and remove the old shape in a later release. Never run destructive migrations automatically without approval. The backwards-compatibility requirement is the substance: during a rolling deploy both versions run simultaneously, so a migration that breaks the old version causes errors for the duration. Candidates who describe deploying schema and code atomically have not thought about rolling updates.

Question 22

What is trunk-based development and how does it affect CI/CD?

Accepted Answer

Developers integrate small changes into a single main branch frequently, behind feature flags for incomplete work, with short-lived branches at most. It suits continuous delivery because main is always releasable and merge conflicts stay small, whereas long-lived branches accumulate divergence and produce risky big-bang merges. The prerequisite to name is a fast, reliable test suite and feature flags — without them, trunk-based development means shipping broken code. Being able to state the preconditions rather than advocating the practice unconditionally is what makes the answer credible.

Question 23

How would you structure CI/CD for a monorepo on GCP?

Accepted Answer

Use path-filtered triggers so a change only builds the affected components; compute the affected set with a build tool that understands the dependency graph; cache aggressively; run component pipelines in parallel; and version and deploy components independently rather than releasing the whole repository together. The failure mode without this is a pipeline whose duration grows with repository size until developers batch changes to avoid waiting, which defeats continuous integration. Naming affected-target computation rather than only path filters shows deeper monorepo experience.

Question 24

What is a private pool in Cloud Build?

Accepted Answer

A private pool runs builds on dedicated workers inside a VPC you control, so builds can reach private resources — a Cloud SQL private IP, an internal artifact server, on-premises systems over VPN — and can use a static egress IP. The default pool runs outside your network and cannot reach private endpoints. The trigger for needing one is almost always a private dependency: integration tests against a private database, or pulling from an internal registry. The static egress IP is the other common driver, when a partner allowlists your outbound address.

Question 25

How do you roll back a bad deployment quickly?

Accepted Answer

On Cloud Run, shift traffic to the previous revision, which takes seconds. On GKE, kubectl rollout undo or, with Cloud Deploy, an automated rollback to the previous release. The prerequisites are immutable artefacts so the previous version still exists, backwards-compatible schema so the old code still works, and a rollback that is practised rather than theoretical. The schema compatibility point is what makes rollback genuinely possible: if the deploy included a destructive migration, rolling back the code does not restore service. That coupling is the most common reason a rollback fails when it is actually needed.

Question 26

What DORA metrics would you track and why?

Accepted Answer

Deployment frequency, lead time for changes, change failure rate and time to restore service. Together they measure both speed and stability, and the research finding is that high performers improve both simultaneously rather than trading one for the other. The insight to state is that speed and stability are not opposed: smaller, more frequent changes are easier to test, review and roll back, so they fail less often and are recovered faster. That reframing is exactly what a DevOps interviewer wants to hear.

Question 27

How do you handle a flaky test suite?

Accepted Answer

Quarantine flaky tests so they do not block the pipeline, but track them as defects with owners rather than deleting them; identify the cause — shared state, timing assumptions, real network calls, test ordering — and fix it; and measure flakiness rate as a first-class metric. The reason this matters is trust: once a red build is assumed to be flaky, real failures are ignored and the pipeline stops protecting anything. Framing flakiness as a reliability problem rather than an annoyance is the mature position.

Question 28

What is the difference between continuous integration, continuous delivery and continuous deployment?

Accepted Answer

Continuous integration is merging and automatically testing every change frequently. Continuous delivery means every passing build is automatically prepared and could be released at any time, with a human decision to release. Continuous deployment goes further and releases every passing build to production automatically with no manual gate. The distinction people blur is delivery versus deployment, and the honest point is that continuous deployment requires very high confidence in automated testing plus progressive delivery and fast rollback. Recommending it for a system without those is reckless, and saying so shows judgement.

Question 29

How would you gate a production deployment for a regulated environment?

Accepted Answer

Require an approval step in Cloud Deploy tied to an identity, with the approver distinct from the author for separation of duties. Require passing automated tests and a vulnerability scan, an attestation via Binary Authorization, a change record, and an automated verification job after deployment. Every step is audit-logged and traceable to the commit. The separation-of-duties requirement — the person who wrote the change cannot be the sole approver — is the control regulators care about most, and it must be enforced by the tool rather than by policy. Naming that enforcement point is what makes the answer concrete.

Question 30

What is infrastructure drift and how does CI/CD address it?

Accepted Answer

Drift is divergence between the declared desired state and the actual deployed state, caused by manual changes. CI/CD addresses it by making the pipeline the only path to change, running terraform plan on every pull request to surface differences, and using GitOps reconciliation where the agent actively reverts unmanaged changes. The organisational half is removing standing human write access to production, so a manual change is not merely discouraged but impossible outside break-glass. A drift-detection job that alerts on differences is the detective control when prevention is not complete.

Question 31

How do you version container images and why does the tag strategy matter?

Accepted Answer

Tag with an immutable identifier — the commit SHA or a semantic version — and deploy by digest where possible, since a tag can be moved but a digest cannot. Avoid deploying "latest", which makes it impossible to know what is running or to reproduce an incident. Deploying by digest is the strongest form because it is cryptographically pinned, so even a compromised registry cannot substitute a different image under the same tag. Naming digest pinning rather than just "do not use latest" is the deeper answer.

Question 32

What is Cloud Source Repositories and would you use it?

Accepted Answer

It is GCP's hosted private Git service with IAM integration and mirroring from GitHub or Bitbucket. Most organisations use GitHub or GitLab for the collaboration features and connect them to Cloud Build, so Cloud Source Repositories is mainly used for mirroring or where all tooling must stay inside GCP. The honest answer is that it is not competitive on developer experience with GitHub or GitLab, and recommending it purely because it is a Google product would be a weak answer. Naming the specific case where it fits — a strict no-external-services requirement — is better.

Question 33

How do you run integration tests that need a database in Cloud Build?

Accepted Answer

Either start the database as a background build step in a container on the shared network and point the tests at it, use the official emulators for Firestore, Pub/Sub, Bigtable and Spanner, or use a private pool with access to a dedicated test Cloud SQL instance. Each test run should get a clean, isolated dataset. Isolation is the requirement that shapes the choice: shared test databases produce order-dependent failures and cross-contamination between parallel builds. Naming per-run schema creation or containerised databases as the isolation mechanism is what makes the answer practical.

Question 34

What does a good pull request pipeline look like?

Accepted Answer

Fast feedback in a few minutes: linting and formatting, unit tests, a build to verify it compiles and the image builds, dependency and secret scanning, an infrastructure plan if the change touches Terraform, and a preview or ephemeral environment for larger changes. Slow tests run after merge or on a schedule. The constraint that drives design is the developer's attention span — a pipeline over about ten minutes causes context switching and batching. Explicitly separating the fast pre-merge gate from the slower post-merge suite is the structural answer.

Question 35

How do you deploy to multiple regions safely?

Accepted Answer

Deploy region by region rather than everywhere at once, starting with the lowest-traffic region, with a soak period and automated metric verification between each. Cloud Deploy models this as sequential targets. Keep the ability to fail traffic away from a region, and never deploy to all regions simultaneously. The reason is blast radius: a simultaneous global deploy means a bad change is a global outage, and a staged one means it is a single-region incident you can shift traffic away from. Naming the soak period and the automated abort criterion is what makes it a real strategy.

Question 36

What is an ephemeral or preview environment and how would you build one on GCP?

Accepted Answer

A short-lived environment created per pull request so reviewers can exercise the change. On GCP, deploy the built image to a Cloud Run service with a per-PR name, or a per-PR namespace in a shared GKE cluster, with a seeded test database, and tear it down automatically when the pull request closes. Cloud Run is particularly suited because it scales to zero, so an idle preview environment costs nothing. The automatic teardown is what stops preview environments from becoming a permanent cost and a source of orphaned resources.

Question 37

How do you handle a dependency with a critical vulnerability discovered in production?

Accepted Answer

Assess exploitability in your context first — is the vulnerable path reachable. Then patch by updating the dependency and running the pipeline; if no patch exists, mitigate with a WAF rule, configuration change or feature disablement. Artifact Registry continuous scanning identifies which running images are affected, and Binary Authorization prevents redeploying the vulnerable image. The assessment-before-panic step is what distinguishes a senior answer: not every critical CVE is exploitable in a given deployment, and treating them all as emergencies exhausts the team. Being able to determine reachability, and having an inventory that answers "which of our images contain this", is the capability being tested.

Question 38

What is the role of Terraform in a CI/CD pipeline?

Accepted Answer

Infrastructure changes go through the same review and pipeline as code: a plan runs on every pull request and is posted for review, and apply runs only after merge and approval, using a dedicated service account with a remote state backend in Cloud Storage with versioning and locking. Terraform manages the infrastructure; the application pipeline manages the artefact. The separation to state is that Terraform should not deploy application versions on every release, because infrastructure and application change at different rates and coupling them makes both slower. Keeping them as separate pipelines with a clear interface is the pattern.

Question 39

How do you measure and improve pipeline reliability?

Accepted Answer

Track build success rate, duration percentiles, flakiness rate and queue time. Treat pipeline failures that are not caused by the change as incidents with owners. Reduce duration with caching and parallelism, reduce flakiness by fixing shared state and timing assumptions, and alert when the main branch is red. The framing that matters is treating the pipeline as a production system with its own SLO, because every developer depends on it. A team that tolerates a 70% build success rate has effectively lost continuous integration, and naming that threshold makes the point concrete.

Question 40

Design an end-to-end CI/CD pipeline for a containerised service on GCP.

Accepted Answer

Pull request triggers Cloud Build to lint, unit test, scan dependencies and secrets, and build the image without publishing. On merge to main, build once and push to Artifact Registry tagged with the commit SHA, run integration tests, generate build provenance and create an attestation. Cloud Deploy creates a release and promotes it: automatic to dev, automatic to staging with post-deploy verification, and to production behind an approval gate with a canary strategy and automated rollback on SLO breach. Binary Authorization enforces attestations at deploy. Terraform manages infrastructure through a separate plan-and-apply pipeline. Secrets come from Secret Manager, and the pipeline authenticates with Workload Identity Federation using per-environment least-privilege service accounts. The closing scenario. The senior markers are build-once-promote-many, attestation-gated deployment, a separate infrastructure pipeline, and per-environment identities — because a single build identity with production access is the most common real-world weakness in otherwise well-built pipelines.

GCP Cloud Build, Artifact Registry & CI/CD Interview Questions and Answers

How to use this set