Building a study plan

Knowing what is on the exam is not the same as being ready for it. In the second week of November 2026, Gwen asks Mateo and Kwame to each take a short diagnostic: twenty original practice questions spread across the four domains, untimed, with a note beside each answer saying how sure they were. Mateo scores well on Domains 1 and 3 but misses several security questions about shared responsibility and IAM. Kwame does well on Domain 3, poorly on Domain 4, and gets three questions wrong that he marked as "sure". "Good," Gwen says. "Now we know where the time should go." This lesson turns a diagnostic like theirs into a study plan you can actually follow.

Start from the exam guide and a diagnostic

A good plan has two inputs: what the exam covers and what you already know. The first comes from the exam guide's domains and task statements, reviewed in lessons 3 to 7. The second comes from a diagnostic. Use a short set of practice questions, ideally twenty to thirty, covering all four domains roughly in proportion to their weights. Do it before you study more, so it shows your real starting point. For each question, record your answer, whether it was right, and how confident you were: sure, unsure or guessing.

Confidence matters as much as correctness. A wrong answer you marked as sure is the most dangerous kind, because it means you hold a mistaken belief you will not think to check. A right answer you marked as a guess is fragile, because it might go the other way on exam day. Kwame's three confident errors, all about pricing options and support plans, became the top of his study list.

Weighting your time

Spread study time using two things together: the domain weights and your gaps. A simple method is to start from the weights, 24, 30, 34 and 12, and then adjust for what the diagnostic shows. If you are strong in a domain, reduce its share; if you are weak, increase it. Never drop a domain to zero, because scoring is compensatory across the whole exam and every domain carries marks.

# Share study hours by exam weight, adjusted for diagnostic gaps
weights = {"Concepts": 24, "Security": 30, "Technology": 34, "Billing": 12}
# Gap factor from the diagnostic: 1.0 = average, higher = weaker
kwame = {"Concepts": 1.0, "Security": 1.0, "Technology": 0.7, "Billing": 1.8}
hours = 30
raw = {d: weights[d] * kwame[d] for d in weights}
total = sum(raw.values())
for d, r in raw.items():
    print(d, round(hours * r / total, 1), "hours")

Concepts 7.2 hours
Security 9.1 hours
Technology 7.2 hours
Billing 6.5 hours

The calculation gives Kwame a plan for thirty hours of study. Technology drops a little because he is strong there; billing rises sharply because it was his weakest area, even though its exam weight is the smallest. The numbers are a guide, not a rule, but they stop the common mistake of spending most of your time on the topics you already enjoy.

A plan in phases

Gwen suggests four phases. In the diagnose phase, which takes a week or less, you take the diagnostic, read the exam guide, and list your gaps. In the learn phase, which takes most of the time, you work through each domain, filling gaps with the relevant course lessons, AWS's own free materials such as AWS Skill Builder and the exam guide, and the AWS documentation and whitepapers for topics you need in more depth. In the practise phase, you take timed practice sets under exam conditions, review every mistake, and keep a mistakes log. In the taper phase, the last few days, you stop learning new material and review your log, the confused pairs from lesson 8 and your signpost list.

Mateo's plan runs from mid-November 2026 to his planned exam in early February 2027. He plans to study four evenings a week for about an hour, with a longer session on Saturdays, and to take two weeks off over the holidays, when the emergency hospital is at its busiest. Kwame plans a shorter, more intense schedule toward his planned online exam in late January: five short sessions a week, with billing first and the confused-pairs list every Friday.

Choosing study material

Use legitimate material. AWS's own resources are the most reliable: the exam guide, the official practice question set and other free courses on AWS Skill Builder, the AWS documentation, and AWS whitepapers such as the overview of AWS and the Well-Architected Framework. Reputable training providers publish courses and practice tests written by their own authors. Avoid exam dumps: collections claiming to contain real exam questions. Using them breaks the AWS Certification Program Agreement, which can lead to a ban and the loss of certifications, and they are often wrong anyway. More importantly, they teach you to recognize questions rather than understand services, which fails the moment the wording changes.

Active study beats passive study. Reading a page twice feels productive, but explaining it aloud, writing a one-line summary from memory, or answering practice questions builds the recall you need on exam day. Mateo uses three techniques. Flashcards with a service name on one side and its one-line job on the other. Teach-back, where he explains a topic to Andre, the operations manager, who knows nothing about AWS. And spaced repetition, where he revisits each topic after a day, a week and a month, which suits a plan that spans the holidays.

Keeping a mistakes log

From the first practice question onward, keep a mistakes log. For every wrong answer, and every right answer you guessed, record four things: the topic, the right answer, why your answer was wrong, and the kind of mistake. Gwen uses four kinds. A knowledge gap means you did not know the fact. A confusion means you mixed up two similar services. A reading error means you knew the answer but misread the question or missed a constraint. A timing error means you rushed. Each kind has a different fix: study for gaps, the confused-pairs method for confusions, the reading routine from lesson 2 for reading errors, and the timing plan from lesson 10 for rushing.

Fitting study into a working life

Most Cloud Practitioner candidates study around a job, and Mateo is no exception. The emergency hospital runs around the clock, and some evenings he is called in to fix a printer or a network switch. Gwen's advice is to plan for interruptions rather than pretend they will not happen. Choose short, regular sessions over long, rare ones: four hours spread across a week stick far better than one four-hour block on a Sunday. Decide at the start of each week which topics you will cover, so that when a session is lost you know exactly what to move, rather than drifting. Keep a few minutes' worth of flashcards on your phone for waiting rooms and lunch breaks. And protect one longer session a week for practice questions and review, because that is where learning turns into readiness.

Use your own work as study material. Every AWS task in the migration is a chance to connect a service to a real need. When Mateo sets up the AWS Backup plan for the pilot, he writes a line in his log: "AWS Backup: central backup policies across EBS, RDS, EFS and S3; replaces tapes; Domain 3, storage." When Lorraine asks why the bill rose in November, he looks it up in Cost Explorer and writes the answer as a Domain 4 note. Studying this way makes the exam feel like a description of work he has already done.

Set a date and work back from it. A booked exam gives a plan its shape, and a plan without a date tends to stretch. Gwen suggests booking once the diagnostic is done and the plan is drawn, with enough weeks for every phase and a margin for illness or work emergencies. If the date turns out to be too early, the rescheduling policy usually allows a change if you act before the deadline; check the current rules when you book. Kwame books his online slot for late January the same week he finishes his plan. Mateo books his testing centre seat for early February, after the holiday rush at the hospital, and writes the date at the top of every page of his study log.

Finally, measure progress, not hours. A plan that says "study ten hours a week" can be met without learning much. A plan that says "by the end of week 3, explain the shared responsibility line for EC2, RDS and Lambda from memory and get eight of ten Domain 2 questions right" can be checked. Gwen asks both candidates to write one such goal for each week of their plan, and to note on Sunday evening whether they met it.

Kwame adds one more line to his plan after hearing this: a single sentence at the top of the page that says why he is doing it. "So that I can explain AWS costs to Lorraine and design BookVet's next version properly." On evenings when motivation is low, Gwen says, the reason matters more than the schedule.