Administering Qorionix

Curriculum

Durations include the exercise and are meant honestly rather than optimistically — a lesson estimated at thirty minutes takes about thirty minutes. A lesson that would run past twenty-five minutes has been split into two.

1. Module 1 · 110 min · 5 lessons

   Identity, and the policy engine that decides

   Almost every intrusion into a company this size starts with a working password, which makes this the module that decides whether the other five ever matter. The through-line is the decision trace: after this module you can answer 'why did that contractor get in?' with a record rather than a theory.

   1. Hands-on lab30 min

      First match wins: the ordered sign-on policy engine

      Rules are evaluated in order and the first match wins. That single property causes most policy misconfiguration, because a permissive rule sitting above a restrictive one makes the restrictive one dead code without any warning. The decision trace is how you find that.

      After this lesson you can

      • Build a three-rule policy and predict, before testing, which rule will win for four different sign-ins.
      • Read a per-rule decision trace and state why each non-winning rule did not apply.
      • Find a rule made unreachable by ordering, using the trace rather than by reading the policy.
      • Explain why first-match-wins was chosen over an aggregate-all-conditions model, and what that costs you.

      Exercise

      Build a policy with a deliberate ordering bug, then find it with the trace

      You need

      • A non-production tenant
      • Two test accounts, one of them privileged

      Steps

      1. Create a restrictive rule requiring a second factor for accounts holding an administrative role.
      2. Create a permissive rule above it allowing any sign-in from your office address range with no second factor.
      3. Sign in as the privileged test account from inside that range. Note that you were not challenged.
      4. Open the decision trace for that sign-in and identify the winning rule.
      5. Reorder the rules and repeat. Confirm the trace now names the restrictive rule.
      6. Write down, in one sentence, the general rule you have just learned about zone-based allowances.

      How you know it worked

      Two traces for the same account and the same source address, naming different winning rules, and you can explain the difference without looking it up.
   2. Hands-on lab25 min

      Adaptive multi-factor and the risk signals behind it

      A risky sign-in gets a step-up challenge and the signal breakdown that triggered it is stored rather than discarded. Step-up is the safest automated action in the entire product, for a reason worth internalising: the user proving their identity is the remediation, so the action is self-correcting when it is wrong.

      After this lesson you can

      • Configure a step-up challenge conditioned on risk rather than applied to every sign-in.
      • Read a stored signal breakdown and identify which signal drove the score.
      • Explain why step-up is autonomous-safe and account suspension is not, in terms a manager will accept.
      • Predict the user-visible effect of your configuration on a normal day, and confirm it.

      Exercise

      Trigger a step-up on purpose and read the signal breakdown

      You need

      • A test account with a second factor enrolled
      • A VPN or a second network

      Steps

      1. Configure step-up for elevated-risk sign-ins, leaving normal sign-ins unchallenged.
      2. Sign in as the test account from your usual network. Confirm no challenge.
      3. Sign in from a materially different network or country. Confirm a challenge.
      4. Open the sign-in record and read the signal breakdown. Identify which signal contributed most.
      5. Now sign in from the unusual network a second time. Note whether the risk score changed and reason about why.

      How you know it worked

      One unchallenged sign-in and one challenged sign-in for the same account, with a stored signal breakdown you can explain for each.

   3. Concept20 min

      Passkeys, hardware keys, and what is not phishing-resistant

      A real WebAuthn ceremony with signature verification: a forged signature, a phished origin and a replayed assertion are each rejected, and each of those was verified against the live route rather than assumed from a library's documentation. Text messages and authenticator push notifications are not phishing-resistant, and this platform does not treat them as though they are.

      After this lesson you can

      • Rank the available factors by phishing resistance and justify the ranking mechanically, not by reputation.
      • Explain what origin binding does and why it is what defeats a proxy phishing kit.
      • Decide which factor to mandate for privileged accounts in your organisation, and what the fallback is when somebody loses it.
   4. Hands-on lab15 min

      Network zones, evaluated before rule matching

      Allow and deny by address range or country, evaluated ahead of policy rules. A sign-in from a denied zone is refused outright, which makes zones the bluntest and most dangerous control in the module — and the one most likely to be configured by copying a list of countries off the internet.

      After this lesson you can

      • Configure an allow zone and a deny zone and predict the interaction between them.
      • Explain why zone evaluation runs before rule matching, and what would break if it ran after.
      • Identify the failure mode where a country-level deny blocks a legitimate user travelling, and choose between blocking and stepping up.

      Exercise

      Deny a country, then break your own access, then fix it properly

      You need

      • A non-production tenant
      • A VPN with an exit in a country you do not operate in

      Steps

      1. Create a deny zone for one country you have no business in.
      2. Connect through a VPN exit in that country and attempt to sign in. Confirm outright refusal, not a challenge.
      3. Now create a deny zone covering your own country, and attempt to sign in normally. You are now locked out.
      4. Recover using whatever break-glass path your tenant has. Note how long it took and write it down.
      5. Replace the country-level deny with a step-up requirement for unfamiliar geography, and reason about which of the two you would actually deploy.

      How you know it worked

      You locked yourself out and recovered without contacting us, and you have a written break-glass procedure that you have now tested rather than assumed.
   5. Hands-on lab20 min

      The permission catalogue and delegated administration

      Named permissions rather than three tiers called admin, user and viewer. The design goal you are configuring towards: an office manager who can reset a password and cannot read the audit log. This module also covers the failure mode where a role exists, is assigned, and grants nothing.

      After this lesson you can

      • Build a delegated role granting exactly one capability, and verify by attempting a second one.
      • Explain what a permission denial on a module you have paid for indicates, and where to look.
      • State why the administrator role is granted every permission that exists rather than an enumerated list.

      Exercise

      Build a password-reset-only role and prove it cannot read the audit log

      You need

      • A test account
      • Permission to create roles

      Steps

      1. Create a role granting the password-reset capability and nothing else.
      2. Assign it to a test account and sign in as that account.
      3. Reset another test user's password. Confirm success.
      4. Attempt to open the audit log. Confirm refusal.
      5. Attempt one module you have not granted — privileged access, or log search. Confirm refusal and note the exact error.

      How you know it worked

      One capability works, three do not, and you can state the difference between a refusal because you lack the permission and a refusal because the organisation lacks the module.

2. Module 2 · 95 min · 4 lessons

   Federation and provisioning

   Getting people in from somewhere else, and getting them out again. The SAML lesson here is unusually long and unusually specific, because inbound federation is the highest-consequence surface in the product and the hardened verifier deliberately rejects assertions that other implementations accept.

   1. Hands-on lab35 min

      Inbound SAML, and why the verifier rejects things your IdP sends

      Configure inbound federation, then deliberately send it four malformed assertions and watch each one be refused. The point is not that you will craft assertions in your job; it is that when a real IdP integration fails, you will know whether the refusal is a bug or the verifier doing exactly what it should.

      After this lesson you can

      • Configure an inbound SAML provider end to end and complete a real sign-in through it.
      • Name the checks performed beyond signature validity — destination, audience, recipient, in-response-to, not-before, replay — and say what each one prevents.
      • Given a refused assertion, decide whether the fix is on our side or in the IdP's configuration.
      • Explain, to a colleague, what signature wrapping is and why a byte-scanning verifier cannot detect it.

      Exercise

      Federate, then get refused four times on purpose

      You need

      • A second identity provider you control — Entra ID, Okta or Keycloak
      • A tool that can replay an HTTP POST, which can be your browser's developer tools

      Steps

      1. Configure the provider, exchange metadata, and complete one successful sign-in.
      2. Capture the successful SAML response.
      3. Replay it unmodified. Confirm refusal, and note that the reason is replay rather than signature.
      4. Change the audience to another value and submit. Confirm refusal.
      5. Change the assertion's subject to a user in a different organisation and submit. Confirm refusal.
      6. Let the assertion expire, then submit it. Confirm refusal.
      7. For each refusal, find the corresponding entry in the audit trail.

      How you know it worked

      One success and four refusals, each with a distinguishable reason, and none of the refusals echoing internal verifier detail back to you — that last part is deliberate and worth noticing.
   2. Hands-on lab20 min

      OIDC, and API keys for the things that are not people

      The OIDC provider surface and where API keys are the right answer instead. Service accounts, CI runners and agents are priced as non-human identities for a reason: they behave differently, they never enrol a second factor, and they are the accounts nobody rotates.

      After this lesson you can

      • Register an OIDC client and complete an authorisation code exchange.
      • Decide between an OIDC client and an API key for three described integrations.
      • State how you would detect an API key that has not been used in ninety days, and what to do about it.
   3. Walkthrough20 min

      Inbound provisioning over SCIM

      Creating users and memberships from an HR or directory system, so that a joiner appears without anybody typing their name twice. Treat this lesson as a preview rather than a deployment: the SCIM path is wired to a shadow store pending a one-line change and is not production behaviour yet.

      After this lesson you can

      • Describe the joiner flow from the HR system to a usable account.
      • Identify which attributes you must map for the platform to be useful, and which are optional.
      • State the current limitation and decide whether to wait for it or provision manually.
   4. Concept20 min

      Leavers, and why deprovisioning is never automated

      Deprovisioning or deleting a user is never automated, at any tier, at any confidence. This lesson is about designing a leaver process that is fast without being automatic, and about why the platform declines to make this particular decision for you.

      After this lesson you can

      • Design a leaver process for your organisation with a target time from notification to access removal.
      • Explain the reasoning behind never automating deprovisioning, including the failure mode it avoids.
      • Distinguish the actions that are available unattended — session revocation, forced password reset, step-up — and why those are safe when deletion is not.

      Exercise

      Time your own leaver process

      You need

      • A test account
      • A stopwatch, honestly used

      Steps

      1. Write down your current leaver process as you believe it works.
      2. Run it against a test account, timing each step.
      3. Note every step that depended on a specific person being available.
      4. Rewrite the process so that no step depends on one named individual, and re-time it.

      How you know it worked

      A written process with a measured elapsed time and no single point of human failure. If your measured time is over four hours, that is worth knowing and is not unusual.

3. Module 3 · 95 min · 4 lessons

   Getting logs in, and proving they arrived

   The most important lesson in this module is the last one, and it exists because of a real defect class: an ingest endpoint can return a success code while dropping every event. Verifying that a log source works means finding the event you sent, not seeing a green tick.

   1. Concept20 min

      The sources that work today, and the ones that do not

      A specific, dated inventory rather than a marketing list. Microsoft 365 and Entra ID, Windows Event Log, syslog and the HTTP event collector are the paths to plan around. Cloud log pulling is the one to be careful about, and this lesson says why in detail.

      After this lesson you can

      • List the ingest paths you will use in your own organisation, in the order you will enable them.
      • State what evidence you would need before believing a source is working.
      • Explain why a source that authenticates successfully is not necessarily a source that delivers data.
   2. Hands-on lab30 min

      Windows Event Log and syslog

      The two collectors most organisations need first. Windows Event Log because that is where the identity and process events are, and syslog because that is what the firewall and the switch speak.

      After this lesson you can

      • Configure Windows Event Log collection and confirm a named event arrives.
      • Configure a syslog source and confirm a named event arrives.
      • Diagnose a syslog source that is configured, reachable, and delivering nothing.

      Exercise

      Send a distinctive event from each source and find it

      You need

      • A Windows host with the sensor installed
      • A device or host that can emit syslog

      Steps

      1. Enable Windows Event Log collection for the Security and System channels.
      2. On the Windows host, generate a distinctive event — a failed sign-in with a memorable username works well.
      3. Search for that username. Confirm the event is present and note how long it took to appear.
      4. Configure the syslog source and point one device at it.
      5. Send a syslog message containing a string you invented.
      6. Search for that string. If it is absent, check whether the source was ever bound to your organisation — an unbound syslog listener accepts traffic and drops all of it.

      How you know it worked

      Both invented strings are findable by search. Not 'the source shows as connected' — findable by search.
   3. Hands-on lab25 min

      One schema, and how to find out what is actually in a field

      A detection rule is written once rather than once per vendor, which requires events from different sources to land in the same shape. This lesson teaches you to inspect what actually arrived rather than to trust a schema document, because the schema documentation and the implementation have disagreed here before.

      After this lesson you can

      • Inspect a raw ingested event and enumerate the fields that are actually populated.
      • Compare the same logical event from two different sources and identify where they differ.
      • Given a detection rule that references a field, determine whether your tenant populates that field.

      Exercise

      Inspect what really arrived, from two sources

      You need

      • Two working log sources from the previous exercise

      Steps

      1. Find one authentication event from Microsoft 365 and one from Windows Event Log.
      2. List, for each, the fields that are populated and the fields that are empty.
      3. Identify a field populated by one source and not the other.
      4. Find a detection rule that depends on that field, and reason about which of your sources it can fire on.

      How you know it worked

      A written two-column comparison, and a correct prediction about which source a specific rule can and cannot fire on.

   4. Concept20 min

      A match is not an alert

      Between a rule matching and a human seeing something there are four gates: tenant overrides, a windowed aggregation with a threshold, a cooldown, and the shadow-mode gate. Most 'why did I not get an alert' questions are answered by one of those four, and knowing which saves you a ticket.

      After this lesson you can

      • Trace a match through all four gates and name the gate that would suppress it in three given scenarios.
      • Explain what a cooldown protects against, and what it costs you.
      • Given a rule that matched and produced no alert, identify which gate stopped it.

4. Module 4 · 105 min · 4 lessons

   The endpoint sensor on a real fleet

   Deployment, and then the part most people skip: confirming that what the sensor sends is behaviourally useful rather than a heartbeat. This module also tells you plainly that you will be updating these agents by hand.

   1. Concept20 min

      What the sensor collects, per platform

      Windows, Linux via eBPF, and macOS, and they are not equivalent. Knowing the per-platform difference decides which detections can fire on which of your machines, which is a coverage question rather than a deployment detail.

      After this lesson you can

      • State, per platform, whether process ancestry and command lines are available.
      • Predict which detections cannot fire on a given platform, and why.
      • Decide what to do about a platform where telemetry is thin.
   2. Hands-on lab35 min

      Deploying to Windows and Linux

      MSI for Windows, deb and rpm for Linux, deployed the way you deploy anything else. The macOS story is different and this lesson says so rather than leaving you to discover it.

      After this lesson you can

      • Deploy the sensor to at least five hosts using your existing deployment mechanism.
      • Confirm each host is present and reporting telemetry, not merely present.
      • Write the rollout plan for the remainder of your fleet, including the update mechanism you will use.

      Exercise

      Five hosts, and a rollout plan that accounts for updates

      You need

      • Five hosts across at least two operating systems
      • Whatever you normally use to push software — group policy, Intune, Ansible, a shell loop

      Steps

      1. Package or wrap the installer for your deployment tool.
      2. Deploy to five hosts.
      3. For each host, generate distinctive activity and confirm it appears with command line and parent process.
      4. Write the plan for the rest of the fleet. It must contain a named mechanism and a named owner for pushing the next version, because nothing in the product will do it.

      How you know it worked

      Five hosts reporting real process telemetry, and a written update plan with a name against it.
   3. Hands-on lab25 min

      Verifying telemetry depth, not agent presence

      A dashboard showing thirty healthy agents and a dashboard showing thirty agents sending nothing useful look identical. This lesson gives you a repeatable check that distinguishes them, and it is the single most valuable habit in this course.

      After this lesson you can

      • Run a repeatable check that proves process ancestry and command lines are arriving from a given host.
      • Recognise the specific failure shape where a host reports a bare heartbeat and nothing else.
      • Add this check to your own monthly routine.

      Exercise

      The four-command telemetry probe

      You need

      • At least one Windows and one Linux host with the sensor installed

      Steps

      1. On each host, run a short chain: a shell spawning a second process which writes a file with a distinctive name.
      2. In the console, search for the distinctive filename.
      3. Confirm you can see the writing process, its parent, and the full command line of both.
      4. Record, per platform, which of those three were present. Any missing element is a coverage gap on that platform.
      5. Save the probe as a script and note the date. Re-run it after every sensor update.

      How you know it worked

      A per-platform table of what the probe found. This is the artefact — not a green dashboard.

   4. Hands-on lab25 min

      Response actions, and which of them you can take back

      Quarantine, isolate, kill a process, and live response. Every one records an undo handle before it acts — which means reversibility is a property of the action rather than a recovery procedure. This lesson has you reverse each of them.

      After this lesson you can

      • Take and reverse a quarantine, and locate the vaulted original by its digest.
      • Isolate a host and un-isolate it, and state what was snapshotted before the change.
      • Explain why an action class with no undo handle is never taken unattended, regardless of confidence.
      • Describe the approval flow a live-response ticket goes through by default.

      Exercise

      Quarantine and isolate a test host, then take both back

      You need

      • A host you can afford to disconnect for two minutes
      • A harmless file you created specifically for this

      Steps

      1. Quarantine your harmless test file. Confirm it is gone from disk.
      2. Find its vault entry and note that it is named by its digest.
      3. Restore it. Confirm the bytes are identical to what you created.
      4. Isolate the host. Confirm from the host that network access is gone.
      5. Un-isolate it. Confirm the host firewall rules match what they were before, not a default set.
      6. Read the audit entries for all four actions and identify the actor on each.

      How you know it worked

      Four actions, four reversals, byte-identical file, pre-existing firewall rules restored, and four audit entries with the correct actor.

5. Module 5 · 100 min · 4 lessons

   Detections, tuning and shadow mode

   The rule library exists; your job is to make it fit your organisation without going blind. Every tuning change records who made it and why, and lowering a rule's severity lowers its risk contribution too — so tuning cannot quietly hide an entity from the risk engine.

   1. Concept25 min

      The anatomy of a detection rule

      Fields, severity, status, ATT&CK mapping, and the false-positive guidance that the validation gate refuses to load a rule without. That last requirement exists because a rule you cannot interpret is a rule you switch off in week two, and a switched-off rule is worth nothing.

      After this lesson you can

      • Read a rule and state what telemetry it needs, what it fires on, and what its documented false positives are.
      • Use the ATT&CK mapping to answer the question 'what are we covered for' in a form an auditor accepts.
      • Explain why the coverage claim excludes two of the fourteen ATT&CK tactics.
   2. Concept20 min

      Shadow mode, and why ten rules are quiet

      A shadow rule records its finding and contributes to risk without creating work for a human. Some rules are in shadow because you put them there while remediating; others are in shadow because they reference fields nothing in your tenant populates, and the validation gate refuses to let them claim to be active.

      After this lesson you can

      • Distinguish a rule you shadowed from a rule that is shadowed because its fields are unpopulated.
      • Find the shadow rules in your own tenant and state the reason for each.
      • Explain why the platform refuses to mark a rule active when its fields are unpopulated, and what that prevents.
   3. Hands-on lab30 min

      Tuning with an audited reason

      Severity, threshold, window, cooldown and suppression are yours to change, and every change records an actor and a reason. This lesson has you tune a noisy rule properly and then predict — before checking — what happened to the affected entity's risk score.

      After this lesson you can

      • Tune a rule that fires too often, using threshold and window rather than by disabling it.
      • Predict the effect of a severity change on the affected entity's risk score, then verify.
      • Write a tuning reason that will still be useful to a colleague in eight months.
      • Choose correctly between suppression, shadow mode and a threshold change for three described situations.

      Exercise

      Tune the noisiest rule in your tenant, properly

      You need

      • At least two weeks of your own ingested data
      • A rule with more than twenty alerts

      Steps

      1. Identify your noisiest rule and read every alert it produced. Classify each as true or false.
      2. If they are all false, work out what your organisation does that the rule did not anticipate.
      3. Change the threshold and window rather than the severity, and write a reason naming the specific business behaviour.
      4. Predict, in writing, what happens to the risk score of an entity that previously triggered it.
      5. Wait a week. Compare the outcome against your prediction.
      6. Find your own tuning change in the audit trail and confirm the reason you wrote is legible.

      How you know it worked

      A materially quieter rule that still fires on the case it was written for, an audited reason a colleague could act on, and a written prediction you have checked.
   4. Hands-on lab25 min

      Bounded threat-hunting queries

      A query interface that is injection-safe by construction rather than by sanitisation, because a hunting interface that can be talked into arbitrary SQL is a vulnerability with a search box on it. This lesson is about asking useful questions inside those bounds.

      After this lesson you can

      • Answer three specific hunting questions about your own estate using the query interface.
      • Recognise the questions the bounded interface cannot express, and what to do instead.
      • Explain the design trade-off between an expressive query language and a safe one.

      Exercise

      Three questions about your own estate

      You need

      • At least two weeks of ingested data from more than one source

      Steps

      1. Ask: which accounts signed in from more than three distinct countries in the last thirty days?
      2. Ask: which hosts ran a command interpreter spawned by an office application?
      3. Ask: which privileged accounts have not signed in for sixty days?
      4. For each, write down the answer and whether it surprised you. Then decide whether any of them should become a tuned rule.

      How you know it worked

      Three answers from your own data, and at least one decision about a rule taken as a result.

6. Module 6 · 120 min · 5 lessons

   Sentinel-Q: reading it, bounding it, defending it

   The module that the exam weights most heavily, because it is the capability the product is sold on and the one most likely to be misconfigured out of either fear or over-confidence. The final lesson is a rehearsal for a real meeting.

   1. Concept25 min

      The decision record, field by field

      Classification, confidence, cited evidence, grounding result, escalation reason. Learn to read these in a fixed order, because reading confidence before grounding is how people reach the wrong conclusion about a decision.

      After this lesson you can

      • Read a decision record in the correct order and state what the platform did and why.
      • Distinguish the four dispositions and name the condition that produces each.
      • Given a decision, determine whether the limiting factor was the tier, the ceiling, the floor or the grounding check.
   2. Concept20 min

      Ungrounded means unauthorised

      A verdict whose citations do not verify cannot become a recommendation, at any confidence. The checks run in that order deliberately, and this is the property that makes the rest of the autonomy design defensible rather than aspirational.

      After this lesson you can

      • Explain the ordering of the grounding check relative to the confidence floor, and why the order matters.
      • Given a confident verdict that was refused, identify grounding as the cause from the record alone.
      • Explain to a sceptical colleague why this design constrains the model rather than trusting it.
   3. Hands-on lab35 min

      Setting the autonomy envelope, per rule and per action class

      Two independent limits combine: your per-rule tier, and the per-action ceiling that applies to everybody. The effective permission is the lower of the two, and for multi-step sequences the chain's autonomy is the minimum of its links rather than the maximum.

      After this lesson you can

      • Set a per-rule autonomy tier and predict, for four named actions, whether each becomes available.
      • Explain why setting the highest tier on a rule does not enable privileged-access grants or account deletion.
      • State what the platform does when the tenant policy lookup fails, and why that fallback is the only safe one.
      • Complete a per-action-class opt-in and articulate the risk you accepted in doing so.

      Exercise

      Raise one rule's tier and prove the ceiling still holds

      You need

      • A non-production tenant
      • A rule you understand well

      Steps

      1. Pick one rule whose decisions you have agreed with repeatedly. Note why you picked it.
      2. Raise its autonomy tier to the acting tier.
      3. Before testing, write down which four actions you expect to become available and which you expect to remain gated.
      4. Trigger the rule and read the decision record. Compare against your prediction.
      5. Find a decision where the proposal exceeded the ceiling and confirm it degraded to a recommendation rather than failing.
      6. Now complete the per-action-class opt-in for the least disruptive class, reading the risk statement rather than skipping it.

      How you know it worked

      A written prediction that matched the record, and at least one decision showing a proposal correctly degraded rather than blocked outright.
   4. Concept15 min

      What is actually running the analysis

      A short and awkward lesson about the model provider. Where the platform is deployed determines whether the grounded agent runs or a deterministic fallback does, and a decision record from the fallback does not look obviously different at a glance.

      After this lesson you can

      • Determine, for a given decision, whether it came from the grounded agent or the fallback.
      • State what capability you lose in the fallback path.
      • Decide what you would tell your manager about this, and put it on your risk register rather than in a drawer.
   5. Judgement25 min

      Defending a decision in a meeting

      Five decisions, each with something a manager will object to: one that acted, one that escalated at low confidence, one where the model was confidently wrong, one that degraded to a recommendation, and one where the fallback path produced the analysis. Your job is the two-minute verbal answer.

      After this lesson you can

      • Explain a decision that acted autonomously, including what would have happened had any condition failed.
      • Explain a low-confidence escalation as correct behaviour rather than as a failure.
      • Concede a case where the platform was wrong, and say what changed as a result.
      • Answer the question 'so can we trust it?' without either overselling or undermining the product.

7. Module 7 · 24 min · 3 lessons

   Plans, add-ons and what actually gets billed

   The 2026-09-27 catalogue change, from the administrator's chair: no annual floors or seat caps any more, a small per-head minimum instead, and add-ons for the one capability you actually need rather than a whole tier upgrade. Self-serve sign-up creates a Free workspace; a paid plan is arranged with us directly today.

   1. Concept10 min

      Reading your own plan and usage

      What each plan actually includes, which of the published allowances are fair use and which are a hard, metered cap, and where in the console to see your own usage against the one that is metered.

      After this lesson you can

      • State your own plan's minimum headcount and explain why it replaced the old annual floor.
      • Name the one allowance that is still a hard cap, and the console screen that shows your usage against it.
      • Explain why upgrading a plan never raises Sentinel-Q's autonomy on its own.
   2. Walkthrough8 min

      Add-ons: buying one capability without a bigger plan

      Settings → Plan & add-ons, end to end: reading the price preview before anything is charged, starting a 14-day trial of an add-on with no card, and what a prorated charge confirmation is actually telling you before you accept it.

      After this lesson you can

      • Add a trial of one add-on and identify, from the confirmation dialog, exactly what would be charged if it were a real purchase instead.
      • Explain why removing an add-on is immediate with a prorated credit, not deferred to the end of the billing period.
      • Decide whether Privileged Access as an add-on or a plan upgrade is the cheaper way to reach a capability, for your own headcount.

      Exercise

      Price, then trial, one add-on

      You need

      • A tenant on Core or Protect
      • The billing:subscriptions.write permission

      Steps

      1. Open Settings → Plan & add-ons.
      2. Find an add-on you do not already have active, and read its per-person price against your own billable headcount.
      3. Start its 14-day trial and confirm the toggle now shows a trial state with a day count.
      4. Open the same add-on's row again and note that Try 14 days is gone — it is a one-time offer per add-on per 12 months.

      How you know it worked

      The add-on's status pill reads 'Trial' with a days-remaining count, and no card was asked for anywhere in the flow.

   3. Concept6 min

      What self-serve sign-up actually creates

      Sign-up always creates a Free workspace today, whatever plan was picked on the form. Core, Protect and Complete are arranged directly with us rather than bought at a checkout. This lesson is short because the honest version fits in one paragraph, and it is the one new administrators ask about first.

      After this lesson you can

      • State what tier a new sign-up is actually created on, whatever plan was selected on the form.
      • Explain where a requested paid plan is recorded, and how to actually get one set up.