If you're studying for the CAD Certified Agile Developer certification, a downloadable practice test PDF is one of the most effective tools in your prep kit. Print it, annotate it, work through it offline — whatever fits your schedule. This guide covers what the CAD exam actually tests, how agile development principles are applied on the job, and how to use practice PDFs to lock in the knowledge you need before test day.
The Certified Agile Developer (CAD) credential is awarded by the International Association of Software Architects (IASA) and validates your ability to apply agile engineering practices in real software development environments. Unlike broad agile frameworks certifications, CAD targets the technical disciplines — the actual coding, testing, and delivery practices that make agile teams work.
The exam focuses on four core competency areas: agile technical practices (test-driven development, refactoring, pair programming), delivery engineering (CI/CD pipelines, build automation, deployment), agile frameworks and ceremonies (Scrum, Kanban, XP), and collaborative development principles (emergent design, clean code, working software over documentation).
Candidates are expected to demonstrate applied knowledge — not just terminology. Questions test whether you understand why a practice exists and how to apply it when constraints or trade-offs arise.
The Agile Manifesto, published in 2001 by 17 software practitioners, established four core values that underpin every agile practice you'll encounter on the CAD exam: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. These aren't slogans — they're decision-making frameworks. CAD questions will present scenarios where you must choose the more agile response, so understand the reasoning behind each value, not just the words.
The 12 accompanying principles flesh out the values. Key ones to internalize: deliver working software frequently (weeks rather than months), welcome changing requirements even late in development, build projects around motivated individuals, and continuous attention to technical excellence enhances agility. The principle about sustainable pace — that agile teams should be able to maintain a constant pace indefinitely — ties directly to TDD, refactoring, and CI/CD practices that prevent technical debt from accumulating.
Scrum is the most widely used agile framework and commands significant weight on the CAD exam. You need to know the five events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), the three roles (Product Owner, Scrum Master, Developers), and the three artifacts (Product Backlog, Sprint Backlog, Increment) — including the Definitions of Done and Ready that make artifacts actionable.
Sprint Planning produces a Sprint Goal and a set of Product Backlog Items the team forecasts it can complete. The Daily Scrum is a 15-minute synchronization event — not a status report. The Sprint Review is an inspection of the Increment with stakeholders. The Sprint Retrospective is the team's self-improvement event focused on process, interactions, and tools.
Common CAD exam traps: the Scrum Master is a servant-leader, not a project manager; the Product Owner is solely responsible for the Product Backlog; sprint length is fixed once chosen (1–4 weeks) and not shortened mid-sprint except in extreme cases.
Kanban complements Scrum as a flow-based approach. Its core practices are: visualize the workflow, limit work in progress (WIP), manage flow, make policies explicit, implement feedback loops, and improve collaboratively. WIP limits are the critical mechanism — they expose bottlenecks by preventing work from piling up at overloaded stages.
Key flow metrics for CAD: cycle time (time from work started to delivery), lead time (time from request to delivery), throughput (items completed per time period), and cumulative flow diagrams (CFDs) for visualizing WIP and flow stability. When WIP limits are respected and cycle times shrink, the team has improved flow efficiency.
TDD is a core technical practice on the CAD exam. The cycle is: Red — write a failing test that describes the desired behavior; Green — write the minimal code to make the test pass; Refactor — clean up the code without changing its behavior, keeping all tests green.
Why TDD matters: it produces a living documentation of system behavior, enables fearless refactoring, catches regressions immediately, and drives emergent design by forcing you to think about interfaces before implementations. CAD questions often ask you to identify whether a given practice follows TDD correctly — watch for scenarios where code is written before tests (that's not TDD) or where refactoring is skipped (that accumulates debt).
Related concepts: unit testing (testing a single unit of behavior in isolation), mocking and stubbing (replacing dependencies to isolate the unit under test), and acceptance test-driven development (ATDD), which extends TDD to user-facing behavior specifications.
Continuous Integration (CI) means every developer integrates their code into the shared mainline at least daily, with automated builds and tests running on every commit. The goal: eliminate integration debt and catch conflicts early. A broken build is the team's highest priority — the pipeline stops until it's fixed.
Continuous Delivery (CD) extends CI by ensuring every successful build produces a release candidate that could be deployed to production. Continuous Deployment goes one step further: every passing build is automatically deployed. Know the distinction for the exam.
A typical CI/CD pipeline: code commit → automated unit tests → static analysis/linting → integration tests → build artifact → staging deploy → acceptance tests → production deploy. Key practices: trunk-based development (short-lived branches merged frequently), feature flags (deploy code without activating features), and blue-green deployments (zero-downtime releases).
Pair programming involves two developers working at one machine: the driver writes code while the navigator reviews, suggests, and thinks strategically. Pairs rotate regularly to spread knowledge and reduce bus-factor risk. Research shows pair programming reduces defect rates significantly while only moderately increasing development time — a net positive when factoring in reduced debugging and rework.
Refactoring is the practice of restructuring existing code without changing its external behavior. It's not rewriting — it's disciplined, incremental improvement: rename a variable for clarity, extract a method to reduce duplication, replace a conditional with polymorphism. The test suite is the safety net that makes refactoring safe. Without tests, refactoring is guesswork.
Agile teams estimate in story points (relative complexity) rather than hours. Story points capture effort, complexity, and uncertainty together. The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) is commonly used because the gaps between larger numbers reflect genuine uncertainty about complex work.
Planning Poker is the standard estimation technique: team members reveal estimates simultaneously to avoid anchoring bias, then discuss discrepancies until consensus. Velocity — story points completed per sprint — is used for forecasting only, never as a performance metric or comparison between teams. T-shirt sizing (XS/S/M/L/XL) is a lightweight alternative for early-stage roadmap planning.
Download the PDF and print it on standard paper. Work through the questions without notes or references — treat it like a real exam sitting. When you're done, score yourself and go back through every question you missed. Don't just read the correct answer; trace back to why you chose the wrong one. Was it a knowledge gap, a misread question, or an ambiguous term?
For knowledge gaps, return to the relevant section of your study materials and read actively — take notes, draw diagrams, connect concepts. For misread questions, practice slowing down on scenarios: identify what the question is actually asking before you read the answer choices. For ambiguous terms, build a personal glossary of agile vocabulary and review it before each practice session.
Use the PDF at least twice: once early in your prep to establish a baseline, and once within a week of your exam date to confirm you've closed your gaps. Combine it with timed online practice to build both knowledge and test-taking stamina.
For additional timed practice, detailed question explanations, and full-length mock exams, visit our CAD Certified Agile Developer practice tests page.