21. Errors during every deploy
During each rolling deploy on Kubernetes, clients see a burst of 502 errors as old pods stop. What should the app do when it receives SIGTERM?
- A.Call process.exit(0) right away, since Kubernetes already moved all traffic to the new pod before sending the signal
- B.Ignore SIGTERM so the pod is never stopped
- C.Stop taking new connections, finish in-flight requests, close the DB pool, then exit
- D.Restart itself in the same container
Show answer
Answer: C. Stop taking new connections, finish in-flight requests, close the DB pool, then exit
Graceful shutdown drains work instead of cutting connections mid-request. Kubernetes sends SIGTERM, waits terminationGracePeriodSeconds, then sends SIGKILL, so the drain must fit in that window. Failing the readiness probe first, or a short preStop delay, gives the load balancer time to stop routing to the pod.
22. Steps git bisect needs
A bug appeared somewhere in the last 1,000 commits. About how many builds do you need to test with git bisect to find the first bad commit?
- A.100
- B.10
- C.500
- D.32
Show answer
Answer: B. 10
git bisect is binary search over history: each test halves the suspect commits. 2^10 = 1,024, so about 10 tests are enough. Automating it with git bisect run and a test script makes this fast.
23. Contract too large to deploy
Deployment fails because the runtime bytecode is 27 KB. What limit was hit, and what is a common fix?
- A.The 24 KB (24,576 byte) code limit; split into libraries
- B.The 64 KB calldata limit; send less constructor data
- C.The block gas limit; deploy at a quieter time
- D.The 32 KB stack limit; use fewer local variables
Show answer
Answer: A. The 24 KB (24,576 byte) code limit; split into libraries
EIP-170 caps deployed contract code at 24,576 bytes. Fixes include moving logic into external libraries or separate contracts, removing unused code, using custom errors instead of long revert strings, and turning on the optimizer (with a low runs value favouring size).
24. Two pipelines for every push
After adding merge request pipelines, every push to a branch with an open MR starts two pipelines. How do you fix this cleanly in GitLab CI?
- A.Disable shared runners for the project so that only one of the two pipelines can start at a time.
- B.Add when: manual to every job so the second pipeline waits for a click.
- C.Remove the stages: list so that each job runs only once per push event.
- D.Add workflow: rules to run MR pipelines and skip branch ones when an MR is open.
Show answer
Answer: D. Add workflow: rules to run MR pipelines and skip branch ones when an MR is open.
A branch pipeline and a merge request pipeline are separate pipeline sources. Top-level workflow: rules decide whether a pipeline is created at all; a common pattern runs on merge_request_event, skips push pipelines when CI_OPEN_MERGE_REQUESTS is set, and still runs on the default branch and tags. GitLab provides a template (Workflows/MergeRequest-Pipelines) for this.
25. Approval before production deploy
Compliance wants a named lead to approve every production deploy, while staging deploys run automatically. How is this usually set up in GitHub Actions?
- A.A comment in the workflow file asking for approval
- B.A separate repository just for the production code
- C.Manual edits to the workflow file before each release
- D.A production environment with required reviewers
Show answer
Answer: D. A production environment with required reviewers
Jobs that reference an environment wait for its protection rules, such as required reviewers or a wait timer, before they start. Environments can also hold their own secrets and limit which branches may deploy. GitLab offers similar protected environments with approvals.
26. Sharing one pipeline across 30 repos
Thirty service repos copy the same build-and-scan workflow, and fixing it means 30 PRs. Which GitHub Actions feature lets them all call one central definition?
- A.A repository_dispatch event from each repo
- B.A shared self-hosted runner for all repos
- C.A reusable workflow triggered by workflow_call
- D.A cron schedule in a central repo
Show answer
Answer: C. A reusable workflow triggered by workflow_call
A workflow with on: workflow_call can be used by other workflows with uses: org/repo/.github/workflows/build.yml@v3. Inputs and secrets are passed in, and versioning the reference lets teams upgrade on their own schedule. Composite actions are another option for sharing steps.
27. git describe fails in CI
A build step uses `git describe --tags` to make the version. It works locally but fails in CI with "No names found". The checkout step uses default settings. What is the likely fix?
- A.Run git init again before the build step
- B.Tag the commit again inside the CI job
- C.Use a larger runner with more disk
- D.Fetch full history and tags, e.g. fetch-depth: 0
Show answer
Answer: D. Fetch full history and tags, e.g. fetch-depth: 0
CI checkouts often fetch only the last commit (actions/checkout defaults to depth 1) and no tags, so git describe finds nothing. Setting fetch-depth: 0 fetches all history and tags. Fetching just the tags is a lighter option for big repos.
28. When rolling updates are unsafe
A legacy app holds an exclusive lock on a file share, so two versions cannot run at the same time. Which deployment strategy fits, and what is its cost?
- A.Rolling update with maxSurge 50% and no downtime
- B.Canary with 10% of traffic on the new version
- C.Recreate: stop all old Pods first, accepting short downtime
- D.Blue-green with both versions serving traffic
Show answer
Answer: C. Recreate: stop all old Pods first, accepting short downtime
Rolling, canary and blue-green all have old and new versions running together for a while. Recreate stops every old instance before starting new ones, so they never overlap, at the price of a gap in service. Plan it for a low-traffic window, or remove the exclusivity to allow safer strategies.
29. Builds pass or fail by runner
On persistent self-hosted runners, some builds pass only because files left by earlier jobs are still on disk. What is the best long-term fix?
- A.Use ephemeral runners that start clean for each job
- B.Run a cleanup script once a week on each runner
- C.Pin each repo to one specific runner machine
- D.Disable caching in all workflows
Show answer
Answer: A. Use ephemeral runners that start clean for each job
Long-lived runners collect leftover files, tools and env changes, which hide missing steps and leak data between jobs. Ephemeral runners (one VM or container per job, then destroyed) make every build start the same. They are also safer, since one job cannot tamper with the next.
30. Secret leaked despite masking
A CI log shows a base64 string that decodes to your API token, though the raw token is masked as ***. What happened, and what is the lesson?
- A.The masking feature is off by default on all CI systems
- B.Masking matches only exact values; never print secrets in any form
- C.Base64 is a form of encryption, so this is safe
- D.The token must be shorter than 8 characters to be masked
Show answer
Answer: B. Masking matches only exact values; never print secrets in any form
Log masking replaces the exact secret string, so encoded, split or transformed versions are not hidden. Base64 is reversible, so the token is exposed. Treat masking as a safety net, avoid echoing secrets or debug env dumps, and rotate any secret that appears.
31. A sensible image scan gate
You want the pipeline to block risky images without stopping all work over CVEs nobody can fix yet. Which gate is common and practical?
- A.Fail the build on any CVE of any severity at all
- B.Never fail; only email a scan report once each month
- C.Fail only if the final image is larger than 500 MB
- D.Fail on Critical or High findings that have a fix available
Show answer
Answer: D. Fail on Critical or High findings that have a fix available
Blocking on fixable high-severity issues forces quick wins, since the fix is a version bump or rebuild. Failing on every CVE, including unfixed lows, blocks delivery and trains people to bypass the gate. Track unfixed findings separately with deadlines and exceptions.
32. What a signed commit proves
Your repo requires signed commits. A reviewer says "all commits are signed, so the code is safe". What do signatures actually show?
- A.That the code has passed a full security review
- B.That none of its dependencies have known CVEs
- C.That a trusted key holder made it and it was not altered
- D.That the commit was built and fully tested in CI
Show answer
Answer: C. That a trusted key holder made it and it was not altered
A commit signature links the commit to a key, showing who created it and that it was not altered after signing. It says nothing about whether the change is good or secure. A stolen key or a careless author still produces valid signatures, so review and testing stay necessary.
33. Applying exactly what was reviewed
In CI you want the apply step to do exactly what reviewers saw in the plan step. What is the right approach?
- A.Run terraform plan, then terraform apply -auto-approve
- B.Run terraform plan -out=tfplan, then terraform apply tfplan
- C.Run terraform plan twice and compare the text
- D.Run terraform apply -refresh=false after the plan
Show answer
Answer: B. Run terraform plan -out=tfplan, then terraform apply tfplan
A saved plan file fixes the exact set of actions, and apply tfplan runs only those. If the state changed since the plan, Terraform refuses the stale plan instead of doing something new. A plain apply re-plans, so it may include changes nobody reviewed.
34. Overly broad GitHub OIDC trust policy
A production deploy role trusts GitHub Actions OIDC with the condition below. What is the problem?
"Condition": {
"StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" },
"StringLike": { "token.actions.githubusercontent.com:sub": "repo:acme/*" }
}- A.OIDC tokens cannot be used with AssumeRoleWithWebIdentity
- B.The audience value must be placed inside the sub claim
- C.Any branch of any repo in the acme org can assume the prod role
- D.The wildcard makes the role impossible to assume
Show answer
Answer: C. Any branch of any repo in the acme org can assume the prod role
The sub claim identifies the repo and the ref or environment that the workflow runs for. A repo:acme/* pattern lets any workflow in the org, including a feature branch, take the prod role. Scope it to something like repo:acme/api:environment:production, and protect that environment with required reviewers.
35. Releasing to 5 percent of traffic first
You want a risky change to receive 5 percent of traffic first, watch error rates, and then expand step by step. Which deployment strategy is this?
- A.Blue-green with an instant full cutover
- B.Recreate deployment
- C.Canary deployment
- D.Big-bang release
Show answer
Answer: C. Canary deployment
A canary sends a small share of traffic to the new version and increases it only while metrics stay healthy, with automatic rollback if they do not. Blue-green switches all traffic at once between two full environments. Recreate and big-bang releases have no gradual exposure.
36. Secrets stolen through a pull request
A GitHub Actions workflow uses pull_request_target and checks out the PR's code, then runs its tests. An outsider opened a PR and your cloud secrets were used from an unknown IP. What went wrong?
- A.GitHub publishes all secrets in public repositories by design
- B.Untrusted PR code ran with access to repository secrets
- C.The outsider guessed the secrets by brute force over the API
- D.pull_request_target workflows cannot read secrets at all
Show answer
Answer: B. Untrusted PR code ran with access to repository secrets
pull_request_target runs in the context of the base repo, with secrets available. Checking out and running the PR's code lets an attacker's script read those secrets. Rotate all exposed secrets, review cloud logs, and use pull_request for untrusted code or require approval.
37. Shadow deployment
What does a shadow deployment of a new model do?
- A.It replaces the old model for half of users
- B.It deploys the model only in a test environment with fake data
- C.It hides the model from monitoring tools
- D.It sends a copy of live requests to the new model and logs its predictions, while users still get responses from the current model
Show answer
Answer: D. It sends a copy of live requests to the new model and logs its predictions, while users still get responses from the current model
Shadow mode tests the new model on real traffic with zero user impact. You can compare predictions, latency and errors with the current model before any user sees the new results. It cannot measure user behaviour changes, which still need an A/B test.
38. Deploying by alias, not version
Your serving config points to a model registry alias such as "champion" instead of a fixed version number. What does this enable?
- A.The model trains itself automatically
- B.Every registered version is served at once
- C.Promotion and rollback by moving the alias, with a clear record of which version it pointed to
- D.The registry skips storing older versions
Show answer
Answer: C. Promotion and rollback by moving the alias, with a clear record of which version it pointed to
An alias is a movable pointer to one version. Promoting a model means moving the alias after checks pass, and rolling back means moving it back. Serving reads the alias but should log the resolved version so every prediction can be traced.
39. p99 doubled right after a release
Ten minutes after a new model version rolled out to all traffic, p99 latency doubled and errors are rising. Traffic is normal. What should you do first?
- A.Start profiling the new model in production
- B.Roll back to the previous version, then investigate
- C.Add more replicas and wait
- D.Disable the latency alert
Show answer
Answer: B. Roll back to the previous version, then investigate
When a change clearly lines up with user impact, restore service first by rolling back, then find the cause safely. Adding replicas may hide the issue but costs money and may not help if the new model is simply slower. Afterwards, add latency checks to the canary stage so it is caught earlier.
40. A matrix build
How many jobs does this GitHub Actions configuration start?
strategy:
matrix:
browser: [chromium, firefox, webkit]
shard: [1, 2]- A.6
- B.2
- C.3
- D.5
Show answer
Answer: A. 6
A matrix creates one job for each combination: 3 browsers times 2 shards is 6 jobs running in parallel. Use fail-fast: false if you want all combinations to finish even after one fails.
