0.6 What This Course Builds

Introduction

This course builds the skills to run an organization's Entra ID: configure it, change it safely, and read what it recorded when something goes wrong. It does that in 11 modules after this one, each made of lessons with a build in your own tenant and an exercise page, two in Module 7, where something has already gone wrong.

This lesson covers how a lesson is laid out, what each phase of the course covers and what it needs in your lab, how an exercise page works, how the exam works, and how to plan the time and licenses the course needs. It ends with that plan written down.

Every lesson follows one layout, so that after the first few you know where to look. An introduction says what the lesson covers. Numbered sections each take one idea, show the evidence for it, and say what it means. The build card at the end turns the lesson into a task in your own tenant.

Where a section configures something, it shows the admin center first, as a callout with the path to follow and the fields you should see, and then the Graph PowerShell that does the same. The order is deliberate.

The admin center is where most people learn a feature and where most colleagues will look; Graph is how the change is repeated, recorded and checked. Seeing both makes it possible to do the task either way and to confirm one against the other.

A callout is read in three parts: the task line in bold, the breadcrumb path through the portal, and then the fields as the page shows them, followed by what they mean. This one, for example, is the check worth making at the start of every module:

The path is written from the admin center's own left-hand menu, as it stood when the lesson was checked. Microsoft renames and moves pages from time to time; when a path no longer matches, the page's name is usually still findable with the admin center's search box, and the fields on it are the same.

Where a section reads something, it shows the output as the tool prints it, including Graph PowerShell's column layout and the sign-in log's own field names. A reader who later runs the same command in their own tenant sees the same shape, with their own values in it.

Each lesson also states its sources at the end, and each technical claim in it was checked against a page opened for the purpose rather than recalled. That matters most for the details that change: role names, portal paths, license tiers and default settings. Where a detail is the kind Microsoft changes, the lesson says what it was checked against and when.

Record cards, the boxed summaries with a label in the corner, are kept for things worth reading as a unit: a decision, a finding, a plan, or a set of values that belong together. They are used sparingly, so that when one appears it marks something to take away.

Each lesson ends with a short summary and its resources, the Microsoft pages it was checked against. Microsoft revises those pages and its portals often. Where a page you open and a lesson disagree, the page is newer, and the difference is worth noticing rather than working around.

The modules are grouped into five phases, and each phase builds on the ones before it.

Phase 1, Architecture and Administration. Identity Architecture and Access Flows sets out how access is obtained in Entra ID and where each control applies, from directory objects and tokens to roles and Active Directory beside the cloud. Tenant Administration and Resilience makes the tenant manageable and recoverable: domains, tenant-wide settings, delegation, administrative accounts, emergency access and monitoring of administration.

Phase 2, Identities and Access. Identity Lifecycle and Groups runs an employee lifecycle, from attributes and groups through joiners, movers and leavers to deletion and restoration. Authentication and Recovery configures how people prove who they are and recover when they cannot. Conditional Access Engineering writes, tests and rolls out the policies that decide which sign-ins are allowed.

Phase 3, Applications and Workloads. Application Integration and Provisioning connects applications end to end, from single sign-on through provisioning to retirement. Workload Identities and Consent governs the identities software uses, their credentials, their permissions and the consent that grants them.

Phase 4, External and Hybrid Identity. External Collaboration brings partners and contractors in and takes them out again, with sponsors, end dates and verified offboarding. Hybrid Identity runs the synchronization from Active Directory and diagnoses it when it goes wrong.

Phase 5, Governance and Operations. Privilege and Governance turns standing privilege into governed, time-bound access, with reviews and access packages. Monitoring, Investigation and Automation operates the tenant: logs, investigation, containment, automation and a rhythm the team can hand over.

Each module is self-contained in one sense: its lessons teach everything its builds need, without sending you back to an earlier module to look something up. What carries forward is the tenant.

A group created during the lifecycle work is used again when Conditional Access is configured, and an application registered early is governed again under privileged access, so skipping a build can leave a later build without its starting point.

The order matters. Conditional Access comes after authentication because a policy can only require a method people have registered. Applications come after Conditional Access because most application access is governed by it. Privileged access comes late because its tools, Privileged Identity Management, access reviews and entitlement management, govern everything built before them. Operations comes last because it runs the whole tenant.

In summary, each phase needs something new in your lab, and the next section takes those needs one at a time:

The summary is for deciding when to start a trial or buy a license. The build cards remain the authority for each task, because a single build sometimes needs more than its phase, and the card says so where it does.

Each phase also needs different roles. The first phase needs few beyond reading; the second needs user, group, authentication and Conditional Access administration; the third needs application administration and, for application permissions to Microsoft Graph, Privileged Role Administrator; the fourth needs external identity and synchronization roles; and the last needs privileged role and identity governance administration.

With P2 in the lab, each is held as eligible and activated when a build needs it:

Activating for each build is slower than holding every role permanently, and that is the point. Each activation is recorded with a reason, so the lab's audit log shows when the highest roles were used and why, which is exactly the record an organization wants for its own administrators.

Northgate's tenant changes through the course in the same order. Its findings early on, such as administrators excluded from multifactor authentication or a single emergency account with no method registered, are dealt with by the modules that teach the controls involved, and later modules show the tenant after those changes.

Licenses follow the summary above. The first phase runs almost entirely on Free, the middle phases on P1, and the last on P2 and Governance, so the cost of the lab rises toward the end of the course rather than the start.

Some pieces are outside Entra ID altogether. The synchronization module needs a Windows Server joined to an Active Directory domain, which can be a small virtual machine in Azure or on your own computer, and which is the largest single piece of setup in the course.

The workload modules need an Azure subscription for a managed identity and an Automation account. Each is described on the build card that first needs it, with what it costs and how to remove it afterwards.

A plan for the course should also say what happens to the lab between phases. A tenant left with P2 trial licenses during a two-week break spends the trial on nothing; a tenant left with a half-built Conditional Access policy enforced may lock out the test users you need next time. Ending each phase with its rollbacks done, or its state written down, makes the next phase start cleanly.

Modules can be taken out of order if you already know an area well, but each assumes the configuration earlier modules built. A module's introduction says what it relies on, and its first lesson starts from the tenant as that module finds it.

Each module ends with an exercise page, and Module 7 with two. It opens on a situation that could arrive on any working day: a ticket, a complaint, a request with a deadline. Something in the tenant is wrong, and the page gives you the evidence an engineer would look at to find it.

The evidence is the configuration as Graph exports it, the relevant sign-in, audit and provisioning records, and command output. The questions ask for a number read from the evidence or an option that explains it, and each answer comes with feedback that says why it is right or what it missed. The fault is always findable from what the page shows.

An exercise page answers its own questions in its feedback, so it can be returned to. A second attempt, a week after the first, is a better test of what stuck than the first attempt was, because the details of the scenario will have faded and only the method remains.

The twelve exercises, in order: an Access Fault Traced Through the Decisions. An Emergency Access Account That Fails Its Test. A Leaver Who Can Still Reach an Application. A User Locked Out With a Lost Device. A Compliant-Device Policy That Blocks an Administrator. A New Starter Who Cannot Reach the Finance Application. An Archiver That Can Read Every Mailbox.

An Integration That Stopped When Its Secret Expired. A Contractor Engagement Ends. A Synced Employee With a Wrong Attribute. An Administrator Who Needs Urgent Temporary Access. A Reported Suspicious Sign-in. Each one turns on a skill its module taught, applied to a case the lessons did not walk through, and each has at least one tempting wrong answer that fixes the symptom instead of the cause.

Most exercises have more than one plausible cause, and the evidence is chosen to separate them. A sign-in failure might be the policy or the method; a provisioning failure might be the mapping or the scope. The questions walk from the symptom to the record that rules each cause in or out, so that the answer is proved by the evidence rather than guessed from experience.

Exercises are analyzed from evidence, so they work identically with or without a tenant. They are also where the course is most like the job: the configuration was built by someone else, the complaint describes the symptom rather than the cause, and the record is the only reliable witness.

Doing an exercise before reading its module's lessons is a fair test of what you already know; doing it after is the check that the module worked.

The course ends with an exam set on a single morning: you are taking over Northgate's tenant from its identity team, and four kinds of work arrive at once. Requests from the business need a design chosen. Faults from the week need a cause found. The tenant needs reviewing against the decisions the course made. And the operational handover needs reading for what it missed.

Every answer is read from evidence on the exam page or chosen from options that describe designs, causes and fixes. Answers are checked on the server when you submit, and a pass issues a certificate that anyone can verify. There is no time limit, and every module is examined at least once.

Two choices fail the exam whatever the score, because they are the two mistakes an identity engineer must never make: granting a permission that no requirement asks for, and enforcing a restriction on the whole tenant without a tested way back in.

Both are taught as rules throughout the course, and both are the kind of mistake that one person makes in a minute and an organization pays for over months.

The four parts mirror what an identity engineer actually does in a week. Design decisions come from requests, faults come from users, reviews come from a schedule or an auditor, and handovers come from people moving on.

Each part takes the skills of several modules at once, which is why the exam comes at the end rather than after each phase: the hardest tasks combine a sign-in record with a group membership, or a policy with an exclusion, in ways only the whole course prepares for.

The evidence on the exam page is the same kind the exercises use, from the same tenant, a few weeks after the course's last module. Names, groups and applications will be familiar, which helps; the faults are new, which is the test.

Take the exam after the last exercise, with time to read every table before answering. The tasks reward reading what the evidence says over what it seems to say, which is the skill the whole course is built on.

The course is long, and planning it saves both money and frustration. The plan needs three things: which phases you will build in a tenant and which as build plans, when each license starts and ends, and which roles your daily account will need when.

Licenses are the part with a deadline. Start a trial or a purchase at the start of the phase that needs it, not the start of the course, so it covers the work rather than the waiting. Before starting a phase that needs a higher tier, check that a test user actually has it:

PS C:\> Connect-MgGraph -Scopes "User.Read.All" -NoWelcome
PS C:\> Get-MgUserLicenseDetail -UserId "lab1@yourlab.onmicrosoft.com" |
    Select-Object -ExpandProperty ServicePlans |
    Where-Object ServicePlanName -like "AAD_PREMIUM*" |
    Format-Table ServicePlanName, ProvisioningStatus

ServicePlanName ProvisioningStatus
--------------- ------------------
AAD_PREMIUM     Success
AAD_PREMIUM_P2  Success

AAD_PREMIUM is the service plan for P1 and AAD_PREMIUM_P2 for P2. A license assigned to the user with both plans showing Success is ready; a plan missing or showing another status means a build that depends on it will fail in a way that looks like a configuration fault. Checking first saves reading a misleading error later.

The same check is available in the admin center, where it also shows how each license reached the user:

A license that arrived through a group follows the group: removing the user from the group removes the license, which is convenient for a lab and a trap if the group is also used for something else. Keeping one group for lab licenses, and nothing else, keeps that simple.

Roles follow the same pattern. Assign or make eligible the roles a phase needs when you start it, and remove them when you finish, so your daily account never holds more than the current work requires. The build cards name each role; the plan just collects them.

Write the plan as dates rather than durations. "Phase three in about two weeks" drifts; "Phase three from the 1st to the 14th, P1 trial from the 1st" can be checked against a calendar, and a trial that would end in the middle of a phase is visible before it happens rather than in the middle of a build.

Time is the last part. Each module's lessons are written to be read and built in a sitting each, with the exercise as a separate sitting. Spreading the course over weeks is fine, provided the log export from the first day is in place, so that the evidence of early builds is still there when later lessons read it:

If the oldest record is more recent than the lab, the export was set up late or paused, and records from before that date are gone. That is worth knowing before a later lesson asks you to find a change you made in the first week.

The build is a plan rather than a change: it decides how you will take the course, and when each license and role is needed.

Keep the plan with the lab record. Each module's first lesson is a good moment to check it against where you are, and to move a date when the course has taken longer than planned, rather than letting a license run out in the middle of a build.

The course runs in five phases, from foundations to operations, each module ending on an exercise analyzed from evidence. Lessons show the admin center first and Graph second, and end on a build in your own tenant or a build plan without one.

The exam hands you Northgate's tenant and fails two mistakes outright, whatever the score. If you do one thing now, put the start date of the first phase that needs a paid license in your calendar.

Resources

Microsoft revises these pages; where a page and this lesson disagree, the page is newer.

• Microsoft Learn: Microsoft Entra licensing
• Microsoft Learn: Product names and service plan identifiers for licensing
• Microsoft Learn: Microsoft Graph PowerShell overview