Certifications · CAPA · associate · mock exam · set 1

CAPA Mock Exam · Set 1

Forty-five multiple-choice questions, sat in one 90-minute closed-book block, weighted to the four official CAPA domains in the same proportion the CNCF weights them — 16 questions on Argo Workflows (36%), 15 on Argo CD (34%), 8 on Argo Rollouts (18%), and 6 on Argo Events (12%) — the exact split from the CAPA blueprint page. Every question below has a full explanation folded underneath it, so you can grade honestly instead of guessing whether your reasoning was right for the right reason. This is Set 1 of two; Set 2 is a separate, unseen paper, held back on purpose so you have fresh material once this one stops surprising you. If you haven't worked through the blueprint, the study plan, and the untimed practice bank yet, start there — this paper measures whether that prep survives a clock, not whether you've read about the four projects.

☺ Explain it like I'm 10

You've studied four robots one at a time — the to-do-list robot, the plan-matching robot, the careful-swap robot, and the doorbell robot. This is the pop quiz that asks about all four, mixed together, in the order a real quiz would ask them, with a clock running and no going back to reread a chapter mid-question. Some questions are about the biggest robot, because it's worth the most marks; some are about the smallest, because it still counts. Underneath every question is the full explanation — not just which answer was right, but why the other three doors were built to look almost right.

🐢🐰Your hosts for this topic: Timmy the Turtle & Remy the Rabbit — Timmy holds the stopwatch for the full 90 minutes and won't stop it for anything, and Remy is this course's quick-recall specialist, which makes him the right host for a paper built to reward fast, correct recall over slow deliberation.

Where Set 1 sits in your CAPA prep

☺ Like you're 10: First you learn each robot separately, then you drill loose questions about them, and only then do you sit the whole timed quiz — in that order, not skipped ahead.

The natural sequence on this course is: read the CAPA blueprint for the four domains and their real weights, follow the study plan's day-by-day build, work the untimed practice bank until nothing there surprises you, and only then sit this paper as your first honest measurement of all four domains at once, under a clock. This paper assigns questions to each domain in the exact proportion the CNCF assigns them — 36% Argo Workflows, 34% Argo CD, 18% Argo Rollouts, 12% Argo Events — so a weak score in one domain here is unusually actionable: it tells you precisely which section of the blueprint to reread, not just that you "did badly" in some vague sense.

StageWhat you doWhat it tells you
1 · Build the vocabularyRead the blueprint and follow the study plan's manifests-from-memory drills.Whether you know the material at all — untimed, open-book.
2 · Drill loose questionsThe practice bank, untimed, reading every explanation even for questions you got right.Whether you can recognize the right answer among convincing distractors.
3 · Sit Set 1This page. One 90-minute block, no pausing, all 45 questions.Your pacing under a clock — can you bank a passing score, not just eventually get there.
4 · Fix gaps, then sit Set 2Re-drill only the domains you missed, then sit Set 2 — a fresh, unseen paper — a day or two later.Whether the gap is actually closed, on material you haven't already seen the answer to.
◆ Why 45 questions in 3 blocks

The CNCF doesn't publish CAPA's real question count — the blueprint's logistics table already says so plainly, and this paper takes that seriously rather than inventing a precision the CNCF itself doesn't claim. 45 was chosen because it splits cleanly into three 15-question, 30-minute blocks across a realistic 90-minute sitting, and because 45 divides by the real domain weights into whole numbers of questions — 16 / 15 / 8 / 6 — without much rounding. Treat that shape as this course's own study scaffolding, not a leaked format.

Sit it like the real thing

☺ Like you're 10: No notes, no open tabs, one sitting, go — and if you're not sure, answer anyway, because a blank answer earns the same zero as a wrong one.

CAPA is online, remote-proctored, and closed-book — no notes, no browser tab, no this course, no colleague, no AI assistant, once the clock starts. Sit this practice paper under the same restriction. Close every other tab, and treat the 45 questions below exactly as you would a locked-down sitting: read the stem once, commit to an answer, and only then open the explanation underneath it — peeking first turns a diagnostic into a comprehension exercise and tells you nothing about whether you'd have gotten there cold.

Linux Foundation multiple-choice exams don't publish a separate penalty for a wrong guess beyond simply not earning the point, so the correct strategy is unambiguous: never leave a question blank. Eliminate what you can, then commit to your best remaining option.

⚠ Format specifics can change — verify before you book

The 90-minute duration and the 75% pass mark reflect the Linux Foundation's own CAPA page and its general Multiple Choice Exam FAQ at the time of writing, per the blueprint's logistics table — but the exact question count is not published for CAPA at all, and this paper's 45-question, 3-block shape is this course's own construction, not a leaked format. This is an independent, unofficial study resource, not affiliated with the CNCF or the Linux Foundation. Confirm current duration, pricing, and pass mark on the official Linux Foundation CAPA page before you register.

Your 90-minute budget

☺ Like you're 10: Forty-five questions, ninety minutes — three even blocks of thirty minutes each, so you can check your pace roughly every half hour.

Forty-five questions in 90 minutes averages exactly two minutes each, and the paper is split into three 15-question, 30-minute blocks so you have a clean checkpoint to compare against, rather than discovering with ten minutes left that you're only on question 20. Every block mixes all four domains, the same way a real exam does — you won't see all 16 Workflows questions bunched together at the start.

90 minutes · 45 questions · 75% pass mark (~34/45) Block 1 Q1–15 · 30 min Block 2 Q16–30 · 30 min Block 3 Q31–45 · 30 min 0 90 Weighted to the four real CAPA domains 🐙 Workflows 36% 🤖 CD 34% 🦫 Rollouts 18% 🐦 Events 12% Every block mixes all four domains, and a blank answer scores exactly the same as a wrong one — never skip one. 75% comes from the Linux Foundation's general multiple-choice FAQ, not a CAPA-specific page — verify it yourself.

If a question runs past about two minutes without you being confident, eliminate what you can, commit to your best remaining guess, and move on — there's no folded worked solution to peek at mid-paper the way a hands-on lab bank might tempt you with, since each explanation sits directly underneath its own question.

The paper — 45 questions in exam order

☺ Like you're 10: Forty-five questions, three blocks of fifteen, every robot mixed into every block — read the stem, pick one answer (or two, when it says so), then check yourself before moving on.

Read each stem once, pick your answer, and only then open the explanation underneath it. Each question is tagged with its domain in parentheses so you can total your score by domain afterward — on the real exam you won't get that label, so once you've sat this paper, consider a second pass with the tags covered to see how many you can still place on content alone. Three questions below are marked (Select TWO), matching the real exam's multiple-response format — full credit requires both correct letters.

Block 1 — Q1–15 (minutes 0–30)

Q1 (🐙 Argo Workflows). Argo Workflows' core template types split into two families: definitions, which actually do something, and invocators, which compose other templates together. Which pair is correctly matched to "invocators"?

Check the answer

C. steps and dag compose other templates into a pipeline; container, script, resource, and suspend are the definitions that do the actual work.

Q2 (🤖 Argo CD). Which three fields, together, form the core of an Argo CD Application spec — describing where the desired state comes from, where it goes, and how synchronization should behave?

Check the answer

B. source names the repo, revision and path; destination names the target cluster and namespace; syncPolicy controls automation. D describes an Argo Events Sensor, not an Argo CD Application.

Q3 (🐙 Argo Workflows). A team needs two steps to run in parallel with each other, but only after a first step finishes. Which template type most directly expresses this as a nested list — sequential outer, parallel inner?

Check the answer

B. steps is literally a list of lists: the outer list runs sequentially, and each inner list runs in parallel. A dag could also express this via dependencies, but the "list of lists" shape described in the stem is steps' defining feature.

Q4 (🦫 Argo Rollouts). A team replaces a plain Kubernetes Deployment with a Rollout object to get canary and blue/green capabilities. Which fields carry over unchanged from the Deployment?

Check the answer

B. A Rollout is a near drop-in replacement: same replicas, selector, and pod template as the Deployment it replaces, with the addition of a strategy block offering canary or blueGreen.

Q5 (🤖 Argo CD). An Application shows sync status Synced and health status Degraded at the same time. What does that combination mean?

Check the answer

B. Sync status and health status answer two independent questions — does live match Git, and is the live resource actually well — so an Application can be perfectly Synced and thoroughly Degraded at once, for example if a correctly-applied Deployment's pods are crash-looping.

Q6 (🐙 Argo Workflows). In a Workflow's spec, what does the entrypoint field do?

Check the answer

B. entrypoint is the name of the template the controller invokes first — typically a dag or steps template that then composes the rest.

Q7 (🐦 Argo Events). Which Argo Events component is a custom resource that runs a listener pod, connects to something outside the cluster — a webhook, an S3 notification, a Kafka topic, a calendar schedule — and publishes each occurrence onward?

Check the answer

C. An EventSource is the listener that connects outward and publishes onto the EventBus. AnalysisTemplate belongs to Argo Rollouts and has nothing to do with eventing.

Q8 (🤖 Argo CD). Before Argo CD applies a source that uses a Helm chart or Kustomize overlay to the cluster, which component renders it into plain Kubernetes manifests first?

Check the answer

B. The repo-server renders source.helm or source.kustomize into plain manifests; the application controller then compares that rendered output against live cluster state.

Q9 (🦫 Argo Rollouts). A canary Rollout's steps list reads: setWeight: 10, then pause: {duration: 5m}, then an analysis step, then setWeight: 50. What does the pause step do?

Check the answer

B. A timed pause holds progression at the current weight for the stated duration, so the canary runs under real traffic for a while before the next step — here, an analysis check — fires.

Q10 (🐙 Argo Workflows). A platform team wants one reusable Workflow definition that many teams' namespaces can reference, without copying the YAML into each namespace. Which resource is Argo Workflows' cluster-scoped equivalent of WorkflowTemplate?

Check the answer

B. WorkflowTemplate is namespaced; ClusterWorkflowTemplate is cluster-scoped and reachable from any namespace via templateRef — exactly the "one definition, many namespaces" scenario in the stem.

Q11 (🤖 Argo CD, Select TWO). A team wants an Application that both (1) automatically deletes any resource removed from Git, and (2) automatically reverts any change made directly against the cluster outside of Git. Which TWO fields under syncPolicy.automated together achieve this?

Check the answer

A and B. prune handles deletions no longer declared in Git; selfHeal continuously reverts out-of-band drift. CreateNamespace=true is an unrelated syncOptions entry, and an empty automated: {} block turns sync automation on but leaves both prune and selfHeal off by default.

Q12 (🐙 Argo Workflows). Which resource is purpose-built for running a Workflow automatically on a recurring schedule — the job that cron would handle outside Kubernetes?

Check the answer

B. CronWorkflow wraps a Workflow spec with a cron schedule, submitting a new Workflow each time it fires.

Q13 (🦫 Argo Rollouts). A canary Rollout sets weight to 10%, intending 10% of live traffic to hit the new version. What additional infrastructure does Argo Rollouts require to make that percentage an accurate traffic split, rather than just an approximation from pod counts?

Check the answer

B. Without a traffic router wired in, Argo Rollouts can only approximate a weight by adjusting pod counts between the stable and canary ReplicaSets — a real percentage split needs a router that understands weighted routing.

Q14 (🐙 Argo Workflows). A Workflow step needs to pass a small string — a batch date — to a later step, and separately pass a large Parquet file produced by an earlier step. Which pairing correctly matches Argo Workflows' two data-passing mechanisms to those two needs?

Check the answer

B. Parameters carry small strings via inputs.parameters / outputs.parameters; artifacts carry files via inputs.artifacts / outputs.artifacts, physically stored in a repository like S3, GCS, or MinIO between steps.

Q15 (🤖 Argo CD). An Application is created with no syncPolicy.automated block at all. What is the practical consequence?

Check the answer

B. With no automated sync policy, Argo CD still detects and reports drift, but waits for a manual (or externally scripted) sync trigger before actually applying anything.

Block 2 — Q16–30 (minutes 30–60)

Q16 (🤖 Argo CD). Two resources in the same Application need to apply in a specific order within a single sync — say, a Namespace before the Deployment that lives in it. Which mechanism controls ordering within one sync operation?

Check the answer

A. Sync waves group and order resources within a single sync — lower-numbered waves apply first, and the controller waits for each wave's resources to be healthy before starting the next.

Q17 (🐙 Argo Workflows). An outputs.artifacts entry in one template writes a file that a later step's inputs.artifacts entry reads back. Where does that file actually live between the two steps?

Check the answer

B. Artifacts pass through a configured artifact repository, not through the pod's local filesystem or the Workflow object itself — which is exactly why the repository configuration is worth getting right before your first pipeline run.

Q18 (🐦 Argo Events). Which Argo Events component is the transport layer both EventSources and Sensors depend on, typically backed by NATS/JetStream (or Kafka)?

Check the answer

A. The EventBus is the shared transport in the namespace — if nothing is firing at all, it's the first component to check, since both EventSources and Sensors depend on it.

Q19 (🤖 Argo CD). A team needs a database migration Job to run once, successfully, before the rest of an Application's resources are applied on every sync. Which resource hook is the correct place to run it?

Check the answer

C. PreSync runs before the main sync applies the rest of the resources — the canonical use case is exactly a database migration that must complete first.

Q20 (🦫 Argo Rollouts). A team already has a working Deployment and doesn't want to delete and recreate it as a Rollout. Which field lets a Rollout drive progressive delivery for that existing Deployment's pods instead of owning its own pod template?

Check the answer

A. workloadRef points a Rollout at an existing Deployment, letting Argo Rollouts drive its progressive delivery without the Rollout owning a duplicate pod template. templateRef is an Argo Workflows field, not a Rollouts one.

Q21 (🐙 Argo Workflows). Which Argo Workflows template type is the correct choice for a step that needs to create or patch a Kubernetes object directly, rather than run a container?

Check the answer

B. The resource template type is built specifically for creating, patching, or deleting a Kubernetes object as a Workflow step.

Q22 (🤖 Argo CD). A platform team wants one "root" Application whose only job is to declare and manage a set of other Applications, so adding a new service means adding one file rather than configuring Argo CD by hand each time. This pattern is called:

Check the answer

B. App-of-Apps is an Application whose own source is a folder of other Application manifests — Argo CD reconciles the root Application, which in turn creates and manages the child Applications.

Q23 (🐙 Argo Workflows). A Workflow needs to pause partway through and wait for a human to click "resume" in the UI before continuing — no container should run during that wait. Which template type is built for this?

Check the answer

A. suspend pauses the Workflow for a fixed duration or indefinitely until a human (or an external call) resumes it — no pod runs while it waits.

Q24 (🦫 Argo Rollouts). Which statement correctly distinguishes an AnalysisTemplate from an AnalysisRun?

Check the answer

B. Template is the recipe, run is the dish: the template is authored once and reused, and each analysis step creates a fresh AnalysisRun carrying its own live measurement and result.

Q25 (🤖 Argo CD). A platform team manages the same Application template across 40 clusters and wants Argo CD to generate one Application per cluster automatically from a single generator, rather than hand-writing 40 Application objects. Which resource is purpose-built for this?

Check the answer

A. ApplicationSet uses a generator (list, cluster, Git directory, and others) to produce many Applications from one template, and keeps them in sync as the generator's inputs change.

Q26 (🐦 Argo Events). Which Argo Events component declares named dependencies, applies filters and boolean conditions across them, and executes a trigger once they're satisfied?

Check the answer

C. The Sensor is the rule-matcher: it subscribes to one or more named dependencies published on the EventBus, filters them, and fires a trigger — commonly submitting a Workflow — once its conditions are met.

Q27 (🐙 Argo Workflows). A container step in a data-processing DAG occasionally fails because of a transient network blip talking to an upstream service. Which field lets the step retry automatically a bounded number of times before the whole Workflow is marked failed?

Check the answer

B. retryStrategy on a template configures automatic retries with a bounded limit and a retryPolicy, without hand-coding retry logic into the container itself.

Q28 (🦫 Argo Rollouts). A platform team wants one analysis definition — say, a standard error-rate check — reusable by Rollouts across every namespace in the cluster, not copy-pasted into each one. Which resource fits?

Check the answer

B. ClusterAnalysisTemplate is the cluster-scoped counterpart to AnalysisTemplate, reusable by any namespace's Rollouts without duplication — the same namespaced-vs-cluster-scoped pattern Argo Workflows uses for WorkflowTemplate.

Q29 (🤖 Argo CD). Which Argo CD resource restricts which Git repositories, destination clusters/namespaces, and resource kinds a team's Applications may use — a tenancy boundary rather than a deployment unit itself?

Check the answer

B. An AppProject groups Applications and constrains what they're allowed to point at — the source repos, destinations, and resource kinds in scope — separate from any individual Application's own spec.

Q30 (🐙 Argo Workflows, Select TWO). Argo Workflows' "Run Data Processing Jobs" competency covers dynamic fan-out — running the same template once per item in a list computed at runtime, rather than a fixed number of tasks written by hand. Which TWO fields support that dynamic fan-out?

Check the answer

A and C. withItems fans out over a static or templated list written into the manifest; withParam fans out over a list produced dynamically, such as a JSON array from a previous step's output. dependencies controls DAG ordering, not fan-out cardinality.

Block 3 — Q31–45 (minutes 60–90)

Q31 (🐙 Argo Workflows). Which two Argo Workflows components divide responsibility this way: one reconciles Workflow objects into running pods, and the other serves the API and the web UI?

Check the answer

A. The workflow-controller is the reconciler that turns Workflow objects into pods; the argo-server exposes the API the CLI and UI talk to. D describes Argo Events components, not Workflows.

Q32 (🤖 Argo CD). An Application's Deployment has a HorizontalPodAutoscaler actively managing its replica count. Argo CD keeps flagging the Application OutOfSync because the live replicas field no longer matches the value declared in Git. Which field should be configured to stop treating that specific field as drift?

Check the answer

B. ignoreDifferences tells the application controller to stop comparing a named field on a named resource — exactly the fix for a field, like HPA-managed replicas, that something else legitimately owns.

Q33 (🐦 Argo Events). Put the following into the correct order an event actually travels through Argo Events.

Check the answer

A. EventSource → EventBus → Sensor → trigger is the exam-worthy sentence: the EventSource listens and publishes, the EventBus transports, the Sensor evaluates its dependencies, and a satisfied Sensor fires its trigger.

Q34 (🐙 Argo Workflows). Inside a Workflow template, which pair of fields declares that a template consumes one named artifact on the way in and produces one named artifact on the way out?

Check the answer

B. inputs.artifacts and outputs.artifacts are the fields that name an artifact and its local path on the way in and the way out of a template.

Q35 (🤖 Argo CD). Under source.helm in an Application spec, which sub-fields let you point at a specific values file and override an individual chart parameter without editing the chart itself?

Check the answer

A. valueFiles names a values file to layer in, and parameters overrides individual keys directly. images and namePrefix are Kustomize-specific, not Helm.

Q36 (🦫 Argo Rollouts, Select TWO). Which TWO fields are core, named parts of a blueGreen strategy, controlling which Service currently receives live traffic and which one previews the new version before promotion?

Check the answer

A and B. activeService points at the Service currently receiving live traffic; previewService points at the one showing the new version before promotion. setWeight belongs to the canary strategy, and dependencies / retryStrategy belong to Argo Workflows.

Q37 (🐙 Argo Workflows). In a dag template, a task lists two other task names in its dependencies field. What does the controller do with that information?

Check the answer

C. The controller builds the actual execution order and parallelism from every task's dependencies field — a task only starts once everything it names has finished, which is exactly how fan-in works.

Q38 (🤖 Argo CD). Under source.kustomize, which sub-fields let you override a container image tag and add a namespace-wide name prefix, without a Kustomize overlay file living in the same repo?

Check the answer

B. images overrides image references and namePrefix adds a prefix, both configured directly in the Application spec's source.kustomize block. valueFiles and releaseName are Helm-specific fields.

Q39 (🐦 Argo Events). A Sensor needs to trigger something other than submitting a Workflow — say, patching an existing Argo CD Application object to provoke a sync. Which trigger type is generic enough to create or patch any Kubernetes object, not just a Workflow?

Check the answer

B. The generic k8s trigger can create or patch any Kubernetes object — a Job, a Deployment patch, or an Argo CD Application patch that provokes a sync — where the argoWorkflow trigger is specifically for submitting Workflows.

Q40 (🐙 Argo Workflows). A step needs to run a short inline Python snippet and capture its stdout as an output, without building and pushing a dedicated container image just for that snippet. Which template type is designed for exactly this?

Check the answer

B. script runs inline source against an interpreter inside a base image and automatically captures its output, unlike container, which expects a fully pre-built image and command.

Q41 (🤖 Argo CD). Which two fields together make up an Application's destination block?

Check the answer

B. destination.server names the target cluster's API endpoint and destination.namespace names the target namespace. A and C describe source, and D describes syncPolicy.automated.

Q42 (🦫 Argo Rollouts). A canary Rollout is aborted mid-flight because its AnalysisRun failed. What happens to the Rollout's state afterward?

Check the answer

B. An aborted rollout shifts traffic straight back to the stable ReplicaSet, but Argo Rollouts deliberately parks it in Degraded rather than quietly retrying — a failed analysis is treated as something that needs a human, not another automatic attempt.

Q43 (🐙 Argo Workflows). A dag task named load has dependencies: [transform-a, transform-b]. What is required before the controller starts the load task?

Check the answer

C. Listing both tasks in dependencies means the controller waits for every named task to complete before starting load — the fan-in that closes out a fan-out/fan-in data-processing DAG.

Q44 (🐦 Argo Events). Which statement correctly contrasts Argo Events with Argo CD?

Check the answer

B. This is the exam-worthy contrast: Argo Events reacts to something happening and creates an object in response, while Argo CD's control loop runs continuously, comparing live state to Git regardless of whether anything just happened.

Q45 (🤖 Argo CD). Argo CD is about to sync an Application into a namespace that doesn't exist yet in the target cluster, and the team wants the namespace created automatically as part of the sync rather than failing. Which syncOptions entry enables this?

Check the answer

B. CreateNamespace=true under syncOptions makes the sync create the destination namespace first if it doesn't already exist, instead of failing.

Score yourself

☺ Like you're 10: Count your correct answers out of 45, compare against the 75% target, then look at which robot cost you the most points — that second part is the useful part.

The Linux Foundation's general Multiple Choice Exam FAQ requires "a score of 75% or above" on LF multiple-choice exams, and CAPA is one — so treat 34 of 45 (75.6%) as a reasonable target to clear comfortably, not as a guaranteed pass/fail line on the real exam, which uses its own question bank and its own count. Verify current pass-mark guidance on the official Linux Foundation CAPA page before you rely on any number here.

DomainQuestions in this paperYour scoreIf under two-thirds, go here
🐙 Argo Workflows (36%)Q1, 3, 6, 10, 12, 14, 17, 21, 23, 27, 30, 31, 34, 37, 40, 43/16The Argo Workflows section of the blueprint
🤖 Argo CD (34%)Q2, 5, 8, 11, 15, 16, 19, 22, 25, 29, 32, 35, 38, 41, 45/15The Argo CD section of the blueprint
🦫 Argo Rollouts (18%)Q4, 9, 13, 20, 24, 28, 36, 42/8The Argo Rollouts section of the blueprint
🐦 Argo Events (12%)Q7, 18, 26, 33, 39, 44/6The Argo Events section of the blueprint
Total45 questions/45~75% (34/45) as a rough target
◆ Key idea

A 34/45 built from four solid domains and a 34/45 built from three near-perfect domains plus a near-zero on one are very different results — the second is one unlucky question draw away from failing the real exam, even though both score the same total here. Always do the per-domain arithmetic, not just the headline number.

Beyond the domain breakdown, sort your misses into two piles, because they mean different things. A question you got wrong because you genuinely didn't know the field or the resource is a real content gap — reread the linked blueprint section and redo the exact question cold in a couple of days. A question you got wrong despite roughly knowing the material — you second-guessed yourself, confused two similarly-named resources like AnalysisTemplate and AnalysisRun, or ran out of time and guessed under pressure — is a speed or confidence problem, not a knowledge gap, and the fix is more untimed reps in the practice bank plus another timed paper, not rereading content you already have.

🎬 At Mission Control
🐰

Remy: Thirty-six out of forty-five! DAGs, sync waves, blueGreen — done, done, done, next!

🐢

Timmy: Which domain hid your misses, Remy? Thirty-six sounds great until one domain swallowed most of them.

🐰

Remy: ...Argo Events. I kept mixing up which component was the transport and which one was the listener.

🐦

Pip: Source, bus, sensor, trigger. I fly that whole sentence in one breath — say it out loud until it's automatic, not just recognizable in a multiple-choice list.

🤖

Recon: That's not a speed problem, Remy — you answered fast and confidently, just about the wrong component. Reread that one table slowly before you sit anything else.

🐙

Olly: Same thing happened to me with fan-out and fan-in last month. Once I actually drew the DAG arrows on paper instead of just reading the YAML, it stuck.

🐢

Timmy: Fix that one gap, then sit Set 2 once it's actually fixed — not before, or you'll just confirm the same gap twice.

✓ Checkpoint

1. Why does this paper assign questions to each domain in the same proportion as the real CAPA weights, rather than spreading them evenly across four piles? 2. What's the safe assumption about guessing penalties on a Linux Foundation multiple-choice exam, and what strategy follows from it? 3. Why is the 45-question, 3-block shape of this paper this course's own construction rather than an official CAPA format? 4. You score 34/45 overall but 1/8 on one specific domain — why is that more actionable than a flat 75% average would suggest? 5. Name the two piles a wrong answer can fall into during review, and why they call for different fixes.

Check your answers
  1. Because that's how the CNCF actually weights the real CAPA blueprint — 36% Argo Workflows, 34% Argo CD, 18% Argo Rollouts, 12% Argo Events — so practicing, and scoring, in that same proportion is the closest a study paper can get to the real thing.
  2. Linux Foundation multiple-choice exams don't publish an extra penalty for a wrong guess beyond simply not earning the point, so the safe strategy is to never leave a question blank — eliminate what you can, then commit to your best remaining guess.
  3. Because the CNCF doesn't publish CAPA's real question count at all — this paper's 45 questions across three 30-minute blocks were chosen because they split cleanly into whole numbers of questions per domain and fit a realistic 90-minute sitting, not because that's a leaked or official format.
  4. Because a flat 75% hides where the gap actually is. A domain score of 1/8 is a concentrated, specific content gap fixable by rereading one section, while an evenly-spread 75% wouldn't tell you where to focus at all — the per-domain breakdown converts an average into a diagnosis.
  5. A genuine content gap — you didn't know the fact at all — calls for rereading the linked blueprint section and redoing the exact question cold later. A speed or confidence problem — you roughly knew it but second-guessed yourself or ran out of time — calls for more timed reps and untimed practice-bank drilling, not rereading content you already have.

That's the full sitting. Reset the timer, close every tab except this one, and let the 45 questions above show you exactly which of the four domains is still soft — then go fix precisely that, and nothing else, before you move on to Set 2.

📝 The two papers

Set 1 (you are here) · Set 2. Both are 45 questions weighted to the same official domain percentages and scored against the same 75% target; see the study plan for when to sit each one, and the CAPA blueprint for the real thing's domains, competencies, and day-of logistics.