Build your weekly study schedule around hours you can repeat during an ordinary working week—not a perfect week with no interruptions.
Give reading, lab work, documentation, and applications separate jobs. Otherwise, the easiest activity can consume all the time while the practical work keeps getting postponed.
The schedule below uses short sessions to prepare a question, a longer block to test it, and a career checkpoint to connect the learning with actual roles. Reduce the scope when necessary instead of abandoning the plan every time work gets busy.
Use short sessions to prepare one testable question
Start the week with a question connected to your target role, such as how group membership affects access to a resource.
Use two short sessions:
| Session | Task | Useful output |
|---|---|---|
| Monday: understand | Read relevant documentation and explain the relationship in your own words | A short answer and any remaining uncertainty |
| Tuesday: plan | Identify the accounts, resource, and expected access behavior | A test you can run during the build block |
Stop before the reading turns into a tour of every related feature. The purpose is to make the practical work easier to begin.
By the longer session, you should know what you're testing and why. That prevents Saturday from disappearing into choosing a project rather than making progress on one.
Reserve one longer block for configuration and testing
A longer midweek or weekend block is useful for work that loses momentum when repeatedly interrupted.
Start with the written test objective. Configure the smallest version that can answer it, then run the positive and negative cases.
Keep a note of the next exact action before you stop. “Continue the lab” is not enough. “Retest the denied account after refreshing its session” is much easier to resume.
The schedule should protect the investigation, not require you to finish every technical problem before you are allowed to rest.
Document while the reasoning is still available
Use a separate short session to capture the result, the evidence, and one limitation.
Do not postpone all writing until the project is “really finished.” By then, the most useful explanation of what confused you may be gone.
A small weekly record can include the question, the change, the test, and what you learned. That record later becomes material for a portfolio or interview.
Documenting troubleshooting without manufacturing drama helps keep those notes factual and useful.
You do not need to turn every session into a polished public post.
Keep one block for the job market
Review suitable openings, update one relevant resume example, or submit an application when you can make an honest case.
This prevents a study plan from drifting away from the work employers are actually describing.
Do not treat every new posting as an instruction to add another technology. Look for recurring responsibilities and compare them with the evidence you are building.
Your learning plan should receive information from the job search, not wait until the search begins months later.
Plan a reduced version for difficult weeks
Write a minimum version of the schedule before you need it. Perhaps that means one focused learning session, one small test, and a brief review of the next step.
Missing a longer session should reduce the scope, not trigger a complete restart. Keep the project in a state you can resume.
A full-time job, family commitments, and limited energy are planning constraints. Ignoring them does not make the plan more ambitious; it makes it less usable.
The execution plan in The Six-Figure IAM Career Playbook connects role selection, three lab areas, and applications. The $9 guide gives you a direction to organize around, while your actual calendar determines the pace.
A sustainable week is one you can repeat and learn from. Start there before promising yourself three perfect hours every night.