Cyber Security Quiz: Ci Cd Security
10 questions · exam conditions
0:00
Ci Cd SecurityQuestion 1 of 10

A release pipeline signs container images using a private key stored as a masked CI variable. The pipeline runs on shared, autoscaled workers. Security personnel are concerned that a malicious build step could extract the key and later sign an unauthorized image outside the pipeline.

Which change BEST addresses this concern while retaining verifiable release signatures?

Replace the stored key with short-lived signing credentials bound to the protected release workload and verify the resulting signer identity.
Continue using the stored key, but calculate the image digest twice before applying the release signature.
Encrypt the stored key with a repository secret that the same release job decrypts before signing the image.
Move the stored key to a dedicated worker that accepts signing commands from every branch of the repository.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Ci Cd Security

Practice Ci Cd Security in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Ci Cd Security, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A release pipeline signs container images using a private key stored as a masked CI variable. The pipeline runs on shared, autoscaled workers. Security personnel are concerned that a malicious build step could extract the key and later sign an unauthorized image outside the pipeline.

Which change BEST addresses this concern while retaining verifiable release signatures?

  1. Replace the stored key with short-lived signing credentials bound to the protected release workload and verify the resulting signer identity. (correct answer)
  2. Continue using the stored key, but calculate the image digest twice before applying the release signature.
  3. Encrypt the stored key with a repository secret that the same release job decrypts before signing the image.
  4. Move the stored key to a dedicated worker that accepts signing commands from every branch of the repository.
Explanation: When you see a question about protecting signing keys in a CI/CD pipeline, think about the core threat model: a compromised build step gaining persistent access to a long-lived secret. The real fix isn't hiding the secret better — it's eliminating the long-lived secret entirely. Option A is correct because it replaces the static private key with short-lived credentials that are cryptographically bound to the specific release workload — think OIDC-based signing flows like Sigstore's Keyless signing. Even if a malicious build step intercepts these credentials, they expire quickly and are tied to a verified workload identity, making them useless for signing unauthorized images later. Crucially, the resulting signature still carries a verifiable signer identity, so auditability is preserved. Option B is wrong because hashing the image digest twice before signing does nothing to protect the key itself. It's security theater — the key remains exposed and the malicious step could still extract it. Option C is wrong because encrypting a secret with another secret that the same job decrypts is circular. The release job has access to both the encrypted key and the decryption secret, meaning any code running in that job — including malicious steps — can reconstruct the private key. Option D is wrong in the opposite direction: moving the key to a dedicated worker but accepting signing commands from every branch dramatically widens the attack surface. Any branch could now trigger unauthorized signatures, which is worse than the original problem. The study tip here: when evaluating key-protection controls, always ask whether the secret still exists in a form that can be stolen. Short-lived, workload-bound credentials are superior to any scheme that merely obfuscates a persistent secret.

Question 2

A repository's CI workflow invokes a third-party build action by a mutable version tag. Pull requests may propose workflow changes, and the action executes with access to a token that can write packages. The organization wants to reduce supply-chain risk without eliminating the action.

Which combination of controls MOST directly reduces the identified risk?

  1. Scan the repository source on a weekly schedule and allow the action to retrieve a permanent write token stored in pipeline variables.
  2. Continue using the mutable tag and rotate the package-write token after every successful pull-request execution to limit credential reuse.
  3. Pin the action to a branch name and allow pull-request jobs to receive a token scoped to all package repositories in the organization.
  4. Pin the action to a reviewed immutable digest and withhold the package-write token from untrusted pull-request executions. (correct answer)
Explanation: When tackling software supply-chain security questions, focus on two independent attack surfaces: code integrity (what code actually runs) and credential scope (what damage that code can do). Strong controls address both simultaneously. The core risk here is twofold: a mutable version tag means the action's code can change without your knowledge — a compromised upstream repository could silently swap in malicious code — and a write-capable token means that malicious code could immediately poison your package registry. Answer D closes both gaps at once. Pinning to an immutable SHA digest guarantees you run exactly the reviewed code, full stop. Withholding the package-write token from pull-request jobs follows the principle of least privilege — untrusted code from a fork or external contributor never touches your registry credentials. Answer A fails on both fronts: weekly scans catch nothing in real time, and storing a permanent write token in pipeline variables gives every job — including compromised ones — persistent, broad access. Answer B keeps the mutable tag, meaning rotation of the token is cosmetic; the underlying code integrity problem remains wide open, and a compromised action could exfiltrate the fresh token before it's rotated. Answer C commits the same tag mistake as B, and scoping the token to all package repositories in the organization actually expands the blast radius rather than containing it. A useful study pattern: when a question mentions both a third-party dependency and a secret/credential, expect the correct answer to harden both independently. Fixing only one is always a distractor.

Question 3

Secret scanning detects a cloud access key in a commit that has already been mirrored, included in a build log, and used by a completed pipeline. A developer removes the key from the latest branch commit and asks security to close the alert.

What is the MOST appropriate next action?

  1. Close the alert because removing the key from the current branch prevents future jobs from reading it.
  2. Revoke and replace the key, investigate its use, and remove exposed copies where feasible before closing the alert. (correct answer)
  3. Rewrite only the primary repository history because mirrors and build logs cannot be used to recover deleted credentials.
  4. Sign the corrected commit so any previous unsigned commits containing the key will no longer be accepted.
Explanation: When a secret is exposed in a version-controlled environment, removing it from the latest commit is just the beginning — not the end — of the response. The core principle here is that exposure scope determines remediation scope. A leaked credential must be treated as compromised the moment it appears anywhere outside your control, because you cannot guarantee who or what has already accessed it. That's exactly why B is correct. The key appeared in a mirror, a build log, and a completed pipeline — three separate systems that may retain copies indefinitely. Simply deleting it from the current branch leaves it recoverable from those locations. The right response is to revoke the key immediately (making it worthless even if recovered), issue a replacement, audit activity logs to detect unauthorized use, and scrub exposed copies where possible. Only then does closing the alert make sense. A is the classic trap this question is designed for. Deleting a secret from the current branch does nothing to the build logs, mirrors, or pipeline history that already hold it. Future jobs may not read it, but past exposure is unaddressed. C misrepresents what rewriting history can accomplish. Even if you scrub the primary repository, mirrors have already ingested the commit, and build logs are typically outside git history entirely. Rewriting one location gives false confidence. D is a complete non sequitur. Commit signing authenticates authorship — it has no mechanism to retroactively invalidate or hide the content of previous commits. Study tip: On security exams, any answer that stops at "removed the bad thing" without addressing revocation and investigation is almost always incomplete. Ask yourself: who else might have a copy?

Question 4

A production admission controller verifies that every container image is signed by the organization's release pipeline. An attacker compromises a dependency before the pipeline retrieves it. The pipeline builds the malicious dependency into an image and signs that image normally.

What is the MOST accurate security conclusion?

  1. Signature verification will reject the image because signed images cannot contain dependencies altered before the build.
  2. The signature proves the image passed all security tests, even if those tests are not represented in an attestation.
  3. The signature can prove an approved pipeline produced the image, but scanning and dependency controls are still required. (correct answer)
  4. The signature prevents the dependency compromise from affecting production because signing encrypts the image contents.
Explanation: When you see a question involving image signing and supply chain security, ask yourself: what exactly does a signature prove, and what does it leave unverified? A cryptographic signature on a container image answers one question — "did an authorized signer produce this?" — but says nothing about what went into the build. Here, the pipeline is working exactly as intended. It retrieves a dependency, builds an image, and signs it. The signature is valid and legitimate. The problem is that the dependency itself was poisoned before the pipeline ever touched it. Because the pipeline never detected the compromise, it signed a malicious image with full authority. This is a classic software supply chain attack, and it exposes the critical limit of signature verification: it authenticates provenance, not content safety. That's why C is correct — the signature genuinely proves an approved pipeline produced the image, but without upstream dependency scanning and controls like pinned versions or SBOMs, malicious content can slip through undetected. A is wrong because signatures make no such guarantee. They don't inspect or constrain what dependencies are included — they simply confirm who signed the artifact. B is wrong because a signature proves nothing about which security tests were run or whether they passed. Attestations (separate cryptographic claims about test results) would be needed for that, and even then, only for tests that were actually performed. D is wrong on two counts: signing is not encryption, and it provides no runtime protection against malicious code that the pipeline already compiled into the image. Remember this pattern: signing proves origin, not safety. Anytime an exam question conflates the two, that answer is a trap.

Question 5

An organization allows pull requests from external contributors. Pull-request jobs run automated tests but do not deploy software. Release jobs run only after a protected branch is approved. Currently, both job types use the same cloud service account, which can read source repositories, push images, and deploy to production.

Which redesign MOST effectively applies least privilege while preserving the required pipeline functions?

  1. Use one short-lived service account for all jobs, but issue its credentials only after each job has started.
  2. Use separate identities: a read-only identity for pull-request jobs and a deployment identity available only to protected release jobs. (correct answer)
  3. Keep the shared service account, but block external contributors from viewing the value of its credential in pipeline settings.
  4. Use separate identities for each repository, but grant every identity permission to push images and deploy production releases.
Explanation: When you see a question about CI/CD pipeline security, think about the principle of least privilege: every identity should have only the permissions it needs, scoped to the exact context where it operates. The attack surface question is critical — what damage could an attacker cause if they compromised a given credential? The right move here is B. Pull-request jobs from external contributors need only read access to run tests — they don't build releases or deploy anything. Giving them a deployment-capable identity is dangerous because a malicious pull request could potentially abuse those permissions. By splitting into a read-only identity for pull-request jobs and a deployment identity locked to protected release branches, you enforce privilege boundaries that match actual job requirements. Neither identity can do more than its specific stage demands. A is a partial improvement — short-lived credentials reduce the exposure window — but using one identity for both job types still means external pull requests run with deployment-level permissions, which is the core vulnerability. Timing doesn't fix scope. C is a common trap. Hiding the credential value from contributors in the UI does nothing to prevent the pipeline itself from using that credential during execution. The permissions are still available to any code running in the job, including a contributor's malicious test script. D sounds like separation, but it's separation by repository rather than by privilege level. Granting every identity push and deploy permissions defeats the entire purpose — you've just created multiple equally-dangerous accounts instead of one. Study tip: On security exams, "least privilege" questions usually have one answer that reduces scope of permissions and a distractor that only reduces duration or visibility. Scope is always the priority.

Question 6

A pipeline builds an image, scans it successfully, and records its tag as application:release. A later job rebuilds the source under the same tag and deploys the new image without rescanning it. The registry permits tags to be overwritten.

Which change BEST ensures that the artifact deployed is the artifact that passed scanning?

  1. Increase scanner sensitivity and allow the deployment job to rebuild the image using the original source commit.
  2. Promote and deploy the scanned image by immutable digest, preventing the release job from rebuilding or retagging new content. (correct answer)
  3. Sign the mutable tag after the first scan and permit later builds to replace the image referenced by that tag.
  4. Compare the source commit identifiers of both builds and deploy when the identifiers are the same.
Explanation: When securing a CI/CD pipeline, the core challenge is artifact integrity: guaranteeing that what you scanned is exactly what gets deployed. The moment a mutable tag like application:release can be overwritten, any guarantee from scanning evaporates — a different image can silently slip under the same name. The safest solution is to reference images by their immutable digest (a cryptographic hash like sha256:abc123...), which is permanently tied to specific image content. Once an image passes scanning, you record its digest and promote that exact artifact to production. No rebuild, no retag — the digest makes impersonation or substitution cryptographically impossible. This is precisely what B does, and why it's correct. A fails because even if scanner sensitivity increases and the commit is identical, rebuilding the image produces a new artifact. Build environments, base layer updates, or dependency resolution can all introduce differences. A new build is not the scanned build. C is a trap. Signing a mutable tag sounds rigorous, but the signature is attached to the tag, not the content. If a later build overwrites the tag, the new image inherits the signed name without inheriting the scan validation — defeating the entire purpose. D seems logical but has the same flaw as A. Matching source commits doesn't guarantee matching artifacts. Two builds from the same commit can produce different images due to non-deterministic build processes. For the exam, remember this rule: tags are aliases, digests are identities. Any security control built on mutable tags is fragile. When you see "ensuring the deployed artifact is the scanned artifact," look for digest-based promotion.

Question 7

An organization rotates the signing identity used by its release pipeline. It must continue running older, legitimately signed images while ensuring that newly submitted images are signed only by the current release identity. Simply deleting the old public key would cause existing deployments to fail revalidation.

Which verification policy BEST satisfies these requirements?

  1. Trust both identities indefinitely for all images because revoking the old identity would invalidate historical releases.
  2. Skip signature verification for existing images and accept any newly submitted image whose registry connection uses TLS.
  3. Trust the old identity for new submissions but require current images to use tags created after the rotation date.
  4. Trust the current identity for all submissions and accept the old identity only for approved historical digests or signing times. (correct answer)
Explanation: When you see a question about key rotation in a CI/CD or container signing context, think about temporal trust scoping — the idea that different identities should have authority over different time windows or artifact sets, not blanket authority forever or none at all. The core challenge here is honoring two competing requirements simultaneously: existing signed images must keep validating (so you can't simply revoke the old key), but the old identity must not be allowed to sign new submissions (otherwise rotation accomplishes nothing security-wise). The policy in D threads this needle precisely — the current identity governs all new submissions, while the old identity's trust is narrowed to a pre-approved set of historical digests or signing timestamps. This means a bad actor can't forge a "new" image under the old key, because the policy rejects any old-identity signature that doesn't match an already-catalogued artifact. A is dangerously broad. Trusting both identities indefinitely for all images removes any meaningful boundary — a compromised old key could sign new malicious images and they'd pass verification. B abandons cryptographic verification entirely for existing images and substitutes TLS for new ones; TLS authenticates the transport channel, not the artifact's provenance or integrity. C reverses the intended security posture — it trusts the old identity for new submissions, which is exactly the behavior you're trying to prevent after rotation. As a study tip, watch for answer choices that solve one half of a two-part requirement while breaking the other. The correct answer in key-rotation questions almost always involves scoped, conditional trust rather than all-or-nothing revocation.

Question 8

A vulnerability scanner blocks releases containing critical findings. A legacy component has a critical finding that the security team determines is not reachable in the deployed configuration. The component cannot be replaced for two months, and developers propose excluding that vulnerability identifier globally from all future scans.

Which response BEST preserves meaningful scanning enforcement?

  1. Create a documented, narrowly scoped exception with an owner, expiration date, and compensating controls for the affected component. (correct answer)
  2. Exclude the vulnerability globally because the current application has demonstrated that the vulnerable code is unreachable.
  3. Lower the scanner's severity classification for every finding from the same component vendor until replacement is complete.
  4. Disable release blocking and rely on the production monitoring system to detect exploitation of the legacy component.
Explanation: When you see questions about vulnerability management and scanner exceptions, the key concept being tested is risk acceptance vs. risk elimination — specifically, how to handle legitimate exceptions without undermining your security controls. The goal of vulnerability scanning is continuous, enforceable oversight. When a genuine exception is needed, best practice demands a structured exception: documented rationale, a named owner accountable for resolution, an expiration date tied to the planned fix, and compensating controls that reduce exposure in the interim. This is exactly what A provides. It acknowledges the business reality (the component can't be replaced immediately) while preserving the integrity of the scanning program — the exception is bounded, visible, and auditable. B is the most tempting distractor, but "unreachable in the current configuration" is not a permanent guarantee. Configurations change, and a global exclusion removes the finding from all future scans across all projects, meaning if that vulnerability appears elsewhere or the configuration shifts, you'd have no visibility. Global exclusions are a classic exception-creep trap. C manipulates the scanner's severity logic based on vendor rather than actual risk, which distorts your entire risk picture. Lowering severity for a whole vendor contaminates findings that may be genuinely critical in other components. D abandons preventive enforcement entirely and shifts to reactive detection — a dangerous downgrade. Production monitoring catches exploitation after it happens, not before. Study tip: On security exam questions, any answer that weakens controls broadly to solve a narrow problem is almost always wrong. Look for the option that contains scope, accountability, and a sunset date — that's the hallmark of sound exception management.

Question 9

A deployment job updates one application in a single production namespace. Its cloud role currently allows creation of identities, modification of network policy, administration of all clusters, and deployment to every namespace. Operations personnel state that emergency rollback is performed through a separate approved workflow.

Which permission model BEST applies least privilege to the normal deployment job?

  1. Retain cluster administration but require two reviewers before the deployment job can request its credentials.
  2. Grant access to every production namespace but deny identity creation and network-policy modification.
  3. Grant short-lived permission to update the designated application in its namespace, leaving broader rollback authority separate. (correct answer)
  4. Grant permanent namespace administration so the job can resolve unexpected release failures without operator involvement.
Explanation: When you see a question about cloud IAM permissions for automated jobs, anchor your thinking to the core least-privilege principle: a job should hold only the permissions it needs, only for as long as it needs them. Permanent, broad access is a liability even if it feels operationally convenient. The scenario tells you this job has one purpose — updating one application in one namespace — and that rollback is handled through a separate approved workflow. That detail is the key. The permission model should reflect exactly that scope: short-lived credentials scoped to the target application and namespace, with nothing extra. That's precisely what C describes. Short-lived permissions minimize the blast radius if credentials are compromised, and keeping rollback authority separate respects the stated operational boundary. A is a governance control, not a permission reduction. Requiring two reviewers before credential issuance is a good approval gate, but it doesn't reduce what the job can do — the cluster-admin role remains dangerously broad underneath that gate. B removes two specific dangerous permissions (identity creation and network-policy modification) but still grants access to every production namespace. This is better than the original, but it's still far wider than one namespace, violating least privilege by scope. D is the opposite of least privilege. Granting permanent namespace administration to avoid operator involvement trades security for convenience — exactly the kind of rationale that leads to breaches. As a study tip: on exam questions about least privilege, watch for answers that add process controls without reducing permissions (like A) or that reduce some permissions but keep excessive scope (like B). True least privilege limits both the type and scope of access simultaneously.

Question 10

A team scans source dependencies when a pull request is opened. After approval, the pipeline builds a container image by installing packages from a base image and an operating-system repository. Images may remain in the registry for several weeks before deployment.

Which scanning strategy provides the MOST complete coverage without treating the initial dependency scan as sufficient?

  1. Scan dependencies at pull-request time, scan the built image before promotion, and periodically rescan stored images for new findings. (correct answer)
  2. Scan dependencies at pull-request time and rely on image signing to identify vulnerabilities introduced during the build.
  3. Scan only the running production container because runtime inspection includes source, dependency, and registry weaknesses.
  4. Scan the base image when selected and skip later scans if its digest remains unchanged through deployment.
Explanation: When securing a software supply chain, you need to think in phases: code dependencies arrive first, then the build process introduces new layers, then images sit in a registry before deployment. A vulnerability can enter at any of these stages, so scanning at only one point leaves blind spots at all the others. Option A is correct because it mirrors these three distinct phases. Scanning at pull-request time catches vulnerable libraries in source code early. Scanning the built image before promotion catches vulnerabilities introduced by the base image, OS packages, or build tooling — things that weren't visible in the source dependencies. Periodic rescans of stored images catch newly disclosed CVEs that emerge after the image was built and cleared, which is critical when images sit in a registry for weeks before deployment. Option B fails because image signing verifies authenticity and integrity — it proves an image hasn't been tampered with — but it says nothing about whether that image contains vulnerabilities. Signing and scanning solve completely different problems. Option C is tempting but flawed. Runtime scanning misses vulnerabilities that never get triggered in production, and waiting until runtime means you've already shipped a vulnerable image. Shifting detection that late defeats the purpose of a secure pipeline. Option D assumes a static risk posture: if the base image digest hasn't changed, surely nothing is new. But the threat landscape changes daily. A package inside that unchanged image may have had a CVE published yesterday, making the unchanged digest irrelevant to your current exposure. Study tip: Watch for questions that tempt you to treat one-time scanning as sufficient. Security posture is dynamic — new vulnerabilities are disclosed continuously, so any strategy that stops scanning after a single checkpoint is inherently incomplete.