0.3 A Tenant You Control

Introduction

Every build in this course changes a tenant: a Conditional Access policy, a role assignment, a connector, a protection setting, a containment action. Those changes apply to everyone in the tenant, and some of them, like isolating a device or revoking an account's sessions, are meant to be disruptive. The builds therefore need a tenant you control, where nobody else is affected and every change is yours to make.

This lesson covers why the builds need their own tenant, how to get one, which licenses each part of the course needs and how to get them as trials, Microsoft Sentinel and what ingestion costs, Defender for Cloud and Azure, Security Copilot in a lab, why logs must be exported from the first day, and teardown.

Every licensing and pricing statement was checked against Microsoft Learn, 8 November 2026; these terms change, so check the current pages when you start.

The course's builds are real configuration, and real configuration has effects:

The first reason is scope. Conditional Access policies, authentication method policies, mail flow protection and Defender settings all apply tenant-wide or to groups within the tenant. A policy written to practice a block blocks real people if the tenant has real people in it. A tenant of your own means the only people a build affects are the test accounts you created.

The second is roles. The builds need the roles that make those changes: Global Administrator to set the tenant up, then Security Administrator, Conditional Access Administrator, Exchange Administrator and others, held through Privileged Identity Management. In an employer's tenant you will not, and should not, hold all of them.

The third is evidence. Each build asks you to read back what your change recorded: the audit entry, the sign-in that the policy affected, the alert the setting raised. In a tenant shared with others, those records mix with theirs; in your own, every record is the result of something you did.

Your employer's production tenant is not a lab. A change there needs the approval and the role its own change process requires, and the course's builds are written for a tenant where you are the only administrator. If you do apply a build at work, apply it through that process, with the course's build card as the plan.

Without a tenant at all, the course still works: each build card has a written route, a build plan you complete on paper against the range, and the reading and proofs are the same.

A lab tenant also lets you make mistakes, which is part of learning configuration. A policy that blocks the wrong sign-ins, or a setting that hides the alert you wanted, costs nothing in a lab and teaches more than a build that worked first time.

Do the builds in a tenant you administer and nobody else depends on, and treat your employer's tenant as somewhere changes go through its own process.

How you get a tenant depends on what you already have. Microsoft's rule is that only paid customers can create a new workforce tenant from the Entra admin center:

Not everyone can use that path, so the routes to a tenant you control, in order of convenience, are these:

If your organization is a paid customer and tenant creation is allowed for you, the admin center creates one in a few steps. If creation is switched off, Microsoft's page says to check the tenant creation setting and, failing that, to be assigned the Tenant Creator role.

Customers on a free tenant or a trial subscription cannot create further tenants from the admin center, and Microsoft points them to signing up for a free Azure account instead, which creates a tenant as part of the sign-up.

Whoever creates the tenant becomes its Global Administrator and its technical contact. Microsoft recommends two permanently assigned, cloud-only emergency access accounts holding Global Administrator, not tied to any one person, and that is the first thing to set up. A Conditional Access policy that locks out every administrator is a real risk in a lab where you are practicing Conditional Access, and the emergency accounts are the way back in.

The second thing is a separate account for daily work. Signing in as Global Administrator for every build is the habit privileged access controls exist to break, and it is easier never to start it. The daily account holds no standing roles; it activates them through Privileged Identity Management when a build needs one.

Name the tenant so it is obviously a lab. Its initial domain, the onmicrosoft.com name, cannot be changed later, and a name that says "lab" keeps you from confusing it with anything that matters.

Create a tenant through the route your situation allows, set up two emergency access accounts and a daily account first, and name it as a lab.

The services the course configures are licensed separately, and the course reaches most of them:

Microsoft 365 E5 covers the largest part: the Defender XDR components, Entra ID P2 with ID Protection and Privileged Identity Management, and Purview's audit, labeling, data loss prevention and insider risk. Microsoft's own guide for evaluating Defender XDR uses Microsoft 365 E5 trial licenses for a pilot, started from the admin center:

Microsoft's evaluation page does not state the trial's length or user count, so read both on the offer when you start it, and record the end date. A lab needs a handful of licensed users, enough to have an attacker, a victim, an administrator and a few bystanders, so the user count rarely matters; the end date always does.

Read back what the tenant holds from Graph PowerShell, and keep the output with the record:

PS C:\> Connect-MgGraph -Scopes "Organization.Read.All"
PS C:\> Get-MgSubscribedSku |
    Format-Table SkuPartNumber,ConsumedUnits,CapabilityStatus

Each line is a license the tenant has, how many are assigned, and whether it is enabled, warned or suspended. A trial that has ended shows its status change here before the services stop.

Microsoft's evaluation guide also describes a trial lab environment as an alternative to piloting in production. It notes that such a lab has no real threat data and that its settings cannot be moved to production, which is exactly what you want for this course: a place to change things freely, where nothing you learn is lost because the configuration is recorded in your build evidence.

Assign the licenses to named test accounts rather than to your daily administrator account, so the users a build affects are always the test ones, and the administrator's own sign-ins stay separate in the records.

Start a Microsoft 365 E5 trial in the lab tenant, assign it to a handful of test users, read the licenses back, and record the trial's end date the day you start it.

Modules 8 to 10 need a Log Analytics workspace with Microsoft Sentinel enabled, in an Azure subscription. Sentinel's terms for a new workspace make a lab cheap:

The trial covers the first 31 days after Sentinel is enabled on a workspace, for the first 10 GB a day ingested into the Analytics tier. Some data is free whatever the volume: Azure Activity, Sentinel's own health table, the Office 365 audit log, and alerts from the Defender products and Defender for Cloud.

The raw Defender and Entra tables are charged, even where their alerts are free, and Microsoft notes that connectors mixing free and paid types let you choose which to enable.

A lab with a handful of users ingests far less than the trial's daily limit. The range shows what a month looks like at the scale of a working organization, from Sentinel's own Usage table:

Usage
| summarize Billable = round(sumif(Quantity, IsBillable == true) / 1024, 1),
    Free = round(sumif(Quantity, IsBillable == false) / 1024, 1),
    Days = dcount(bin(TimeGenerated, 1d))
| extend PerDay = round(Billable / Days, 1)

189.2 GB billable over 31 days, 6.1 GB a day on average, and 17.4 GB free. The largest billable types are AADNonInteractiveUserSignInLogs, EmailEvents, SigninLogs: sign-ins and mail, which grow with every user. A lab tenant's volume is a small fraction of that, which is why the trial covers it.

Two charges are worth watching even in the trial. Automation, the Logic Apps that playbooks run on, is charged from the first run. And retention beyond 90 days is charged, so a workspace kept after the course should have its retention set deliberately rather than left at whatever a build chose.

The Usage table is the place to read a workspace's cost before the bill arrives. The same query run in your workspace shows what each data type contributes, and reading it weekly is a habit worth starting in the lab.

Enable Sentinel on a new workspace in the lab, connect the free sources first, and read the Usage table weekly so the trial's end holds no surprise.

Module 6 configures Defender for Cloud on Azure workloads, which needs an Azure subscription with something in it to protect. Defender for Cloud's free tier and its trial cover the course's builds:

Enabling Defender for Cloud gives Foundational CSPM at no charge: recommendations, asset inventory, secure score and regulatory compliance against the Microsoft cloud security benchmark.

The paid plans, such as Defender for Servers, Storage and Key Vault, are free for the first 30 days or until a usage limit, whichever comes first, and charge after that. Microsoft names one exception: malware scanning in Defender for Storage is not in the trial and is charged from the first day.

The workloads themselves cost money whatever Defender for Cloud does: a virtual machine runs by the hour, storage by the gigabyte. Module 6's builds use the smallest resources that show the configuration working, and tear down cleanly. A lab that leaves a virtual machine running after the module is the most common way a course costs more than expected.

The Azure subscription also hosts the Sentinel workspace and any Logic Apps, so it is the place all of the course's Azure costs appear. Setting a budget with an alert on the subscription, at an amount you are comfortable with, is a one-time step that turns an unexpected cost into an email rather than a bill.

Microsoft's page notes that turning a plan off leaves its extensions installed, and that they stop collecting data shortly afterward. At teardown, turning the plans off is the first step, and deleting the resources the second.

Put every lab resource in one resource group named for the course, so teardown is one deletion and nothing is left behind in a group you forgot.

Use Foundational CSPM freely, turn on the paid plans only for the module that needs them, set a budget alert on the subscription, and turn the plans off when the module is done.

Module 11 uses Security Copilot, which is the hardest part of the course to license in a lab:

Microsoft includes Security Copilot with Microsoft 365 E5 and E7, with an allocation of 400 security compute units a month for every 1,000 paid user licenses, scaled below 1,000.

For a lab of 5 paid E5 licenses that is 2 units a month, which is enough for a few prompts and little more. The allocation is computed from paid licenses, so a tenant on an E5 trial should not plan on it.

The alternative is provisioned capacity, set up in Azure and billed for every hour it exists, whether or not it is used. For a lab that is the most expensive option in the course, and the one most likely to be left running by mistake. If you provision capacity for Module 11, delete it the day you finish the module.

The route most students take is the one that needs no Copilot at all. Module 11's method is checking Copilot's answers against the record, and its exercise does that on answers recorded on the range. Everything the module teaches about claims, bounds and verification can be learned there, and the builds that need Copilot in your tenant are marked as such.

That choice is worth making deliberately. Microsoft changes Security Copilot's licensing often, and the terms on the day you reach Module 11 may differ from the ones checked here. Read the inclusion page again then, and decide from what it says.

Whichever route you take, record it in the lab's dates record, so the choice and the terms it was made on are there when you return to the module.

Plan Module 11 on the range, use the E5 inclusion if your lab has paid licenses, and if you provision capacity, delete it the day you finish.

Several builds read back a change you made earlier: the sign-in a policy affected, the audit entry for a role you assigned, the risk detection a test raised. Entra keeps those records for a limited time:

Sign-in and audit logs are kept for 7 days on Entra ID Free and 30 days on P1 or P2. Microsoft notes that collection starts when the license is signed up for, that retention changes are not retroactive, and that data which has expired cannot be recovered unless it was archived earlier. A build done in week one and read back in week six will find nothing in Entra.

The fix is to export from the first day. Diagnostic settings in Entra send sign-in and audit logs to a destination you choose; for this course, the Sentinel workspace, where the first 90 days of retention are free and the logs sit beside everything else the course connects. Setting this up is part of the build below, before any other build runs.

The same reasoning applies to the other services. The Defender portal keeps advanced hunting data for a limited period, the unified audit log has its own retention by license, and Defender for Cloud's alerts arrive in the workspace only once its connector is on. The course's Sentinel module configures all of them; the Entra export comes first because it is the one most builds read.

An export set up late is still worth setting up; it just cannot recover what has already gone. If you set up the lab some weeks before starting the builds, check the oldest sign-in in the workspace against the day you created the tenant.

Check it the next day: a query on SigninLogs in the workspace should return the sign-ins you made setting the lab up.

Send Entra's sign-in and audit logs to the lab's Sentinel workspace on the day you create the tenant, before any build runs.

The course works without a tenant. Every build card has a written route: a build plan you complete against the range, naming what you would configure, in which order, with which role and license, what you would expect to see, and how you would undo it.

The plan is evidence of method, and for the exam it serves the same purpose as a build in a tenant, because the exam asks for reasoning from records, which the range supplies.

For students who do build, the lab ends with teardown, in an order that stops the costs first:

The order matters because costs run until the thing that incurs them is gone. Azure resources and Defender for Cloud plans charge by the hour or the day; a Sentinel workspace charges for ingestion and retention beyond the free amounts; provisioned Copilot capacity charges every hour it exists.

Read each trial's terms for what happens at its end, and cancel any you do not mean to keep before the end date, so nothing continues on terms you did not choose.

Before deleting anything, keep the evidence. Each build's export, query result and note is the record of what you learned, and some of it is what the exam asks for. A folder of exports costs nothing to keep; a deleted workspace cannot be queried again.

The tenant itself can be kept for the next course. A tenant with no licenses and no Azure resources costs nothing, and the next course that needs a lab can start from it. Microsoft documents a set of checks a tenant must pass before it can be deleted, starting with its subscriptions being deprovisioned, and an empty tenant kept for later is usually the simpler choice.

Keep the evidence, stop the costs in order, cancel the trials you will not convert, and keep the empty tenant for the next course.

The build creates the tenant every later build in the course runs in.

The builds need a tenant you administer and nobody else depends on. Paid customers create one from the Entra admin center; everyone else signs up for a free Azure account. Set up two emergency access accounts and a daily account first.

A Microsoft 365 E5 trial covers most of the course; Sentinel's first 31 days are free up to 10 GB a day, Defender for Cloud's paid plans for 30 days, and Security Copilot is best learned on the range.

Entra keeps sign-ins for 30 days at most, so export them to the workspace on the first day. If you do one thing this week, create the lab tenant and record every trial's end date.

Resources

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

• Microsoft Learn: Create a new tenant in Microsoft Entra ID (checked 8 November 2026)
• Microsoft Learn: Evaluate and pilot Microsoft Defender XDR (checked 8 November 2026)
• Microsoft Learn: Plan costs and understand Microsoft Sentinel pricing and billing (checked 8 November 2026)
• Microsoft Learn: Enable Defender for Cloud on your Azure subscription (checked 8 November 2026)
• Microsoft Learn: Microsoft Entra data retention (checked 8 November 2026)
• Microsoft Learn: Security Copilot with Microsoft 365 E5 and E7 (checked 8 November 2026)