CogniSkill · Intune and Endpoint Management Fundamentals

Content review copy. This does not replace the site theme. For SC-300, this preview shows additions; the existing teaching is retained on import.

What you will make

Separate enrollment, policy delivery, compliance and actual resource access.

What you need

Understand users, devices and basic cloud administration.

Use a synthetic device report. No tenant enrollment or live policy changes are required.

How to work through it

Scope

A focused practical workshop, not a complete beginner-to-expert programme. Allow time for the exercises and project; the pace depends on your prior experience. Related CogniSkill books are optional next steps. No purchase is required.

Applied capability and learning route

Separate enrollment, configuration, compliance and access-control evidence.

Follow the lessons in order: establish the model, trace the supplied evidence, attempt the case, compare the worked solution, and complete the changed-condition project. The target is intermediate reasoning within this stated scope, not mastery of the entire profession or product. If a prerequisite is unfamiliar, pause and use the linked foundational teaching before attempting the project.

All teaching, explained answers and core synthetic practice are free. Some operational labs require separately available software, a licensed test tenant or an authorized lab; offline completion does not claim hands-on product proficiency.

How to complete this course

Study the worked examples, attempt the exercises before opening solutions, and submit your own project notes. Completion records are self-reported; practical competence requires the stated verification.

Separate enrollment, delivery, compliance and access

Your practical task

Separate enrollment, policy delivery, compliance and actual resource access.

An enrolled laptop is marked noncompliant even though a settings policy is assigned. The support team assumes enrollment guarantees compliance. Use a fictional device evidence sheet to isolate assignment, delivery and evaluation before making changes.

How the system works

A managed-device record, a successfully applied configuration and a compliance result are different signals. Assignment depends on the target identity or device group, supported platform and policy applicability. A pending status can reflect delivery delay or an offline endpoint, not necessarily a conflicting setting. Compliance must be interpreted with its evaluation time and requirements.

Separate enrollment, delivery, compliance and access

Enrollment establishes a management relationship. Assignment determines which policy/app is targeted. Delivery depends on the device and service conditions, including check-in. Compliance is an evaluation against applicable requirements. Resource access can use that signal alongside other controls. These stages are related but not interchangeable.

A device visible in inventory is not proof that every policy applied successfully. Record identity, ownership, platform, assigned policy, last check-in, setting result and the actual access request. A compliance problem can originate from an unmet requirement or stale/missing evidence; name which condition the supplied data supports.

Reasoning model

Device management comprises different states. Enrollment establishes a management relationship; configuration delivery requests settings; compliance evaluation measures against a policy; access enforcement may consume that result through another control. A device being listed as managed is not proof of compliance or application access. Timing, assignment and check-in matter, so record when each state was observed and avoid interpreting stale information as a current guarantee.

Official reference for further study

Worked four-device triage

Prepare the lab

Use a synthetic device report. No tenant enrollment or live policy changes are required.

Device  Enrolled  Last check-in  Configuration  Compliance  Resource access
LAB-A   yes       10:55 UTC     applied        compliant   allowed
LAB-B   yes       yesterday     pending        unknown     denied
LAB-C   yes       10:58 UTC     conflict       noncompliant denied
LAB-D   no        none          none           unknown     denied
Assessment: 2026-10-07 11:00 UTC

Work through the evidence

Trace management state

LAB-D is not enrolled in this fixture. A missing policy status is not a delivery bug until the management prerequisites are established.

Inspect freshness

LAB-B has a stale check-in. Determine whether the device is online and whether enrollment is healthy before interpreting pending as a policy contradiction.

Read assignment scope

For each device record platform, ownership, group membership and exclusions. A policy assigned to a different group is not evidence of failed delivery.

Expected baseline result

A passes the stated fixture checks; B needs freshness/delivery investigation; C needs setting conflict analysis; D needs enrollment prerequisites. None calls for blanket exclusions.

Worked four-device triage

A Windows pilot policy targets Group P. Device A is in P and reports the expected setting. B is outside P. C is in P but its last check-in predates the assignment. D is in P and reports a conflicting setting result.

A is a positive sample, not proof for the fleet. Investigate B's intended scope before changing membership. For C, obtain fresh delivery/check-in evidence rather than declaring the setting ineffective. For D, inspect the conflict and competing assignments. Re-enrolling every device would discard useful distinctions and introduce unnecessary disruption.

Evidence laboratory — attempt before reading the solution

Synthetic pilot: D1 enrolled, target policy assigned, latest check-in10:00, compliant at10:02, app access tested10:05 succeeds. D2 enrolled, policy assigned, last check-in yesterday, current compliance unknown, app not tested. D3 enrolled but excluded by an assignment filter, no policy evaluation. D4 compliant at09:00, then loses network connectivity before the10:00 test. Requirement: verify current policy delivery, evaluation and intended access for every pilot device. Classify each device’s evidence gaps.

Official reference for further study

Exercise: compliant but access denied

Change the evidence

Resolve a conflict narrowly

LAB-C needs the actual setting and competing assignments. Compare desired values and ownership rather than disabling every security configuration.

Separate compliance and access

LAB-A is compliant and allowed in the fixture, but those facts do not prove that every application permits it. Resource policy, user assignment and authentication remain separate layers.

Design a pilot

Choose representative platforms, a delivery deadline, known-good baseline and rollback owner. Capture the setting on the endpoint and management reports where available before wider release.

Diagnose failures

Pending is treated as conflict

Check delivery, connectivity and freshness first.

Compliant device gets 403

Investigate the actual access decision and application permissions.

One platform fails all settings

Review platform support and enrollment prerequisites before changing every policy.

A second worked example

Device: LAB-14; enrollment: present
Assigned configuration: encryption requirement
Last check-in: before policy assignment
Compliance: encryption not evidenced
Next check: updated policy delivery and evaluated status

The stale check-in means you cannot assume the new configuration was delivered. Inspect current assignment and the device’s next authorized check-in/result. Then evaluate whether the requirement is met and why compliance reports its state. Do not simply mark the device compliant or weaken access policy to hide the issue.

Transfer exercise

A policy targets a group but the device is excluded by a filter. What should you record?

Worked transfer answer

Record the effective targeting decision, relevant group/filter details and whether the exclusion is intended. If the assignment is wrong, correct the approved targeting configuration. Do not infer a client failure when the device is outside effective scope.

Exercise: compliant but access denied

Device A is compliant, yet a user cannot open a business app. What evidence is still missing?

Worked reasoning

Compliance is one input, not universal permission. Collect the user, tenant, target app, time, applicable access-policy evaluation and app entitlement. Confirm the sign-in actually carries the intended device context. Do not weaken the compliance policy simply because an unrelated authorization layer may have denied access.

Worked laboratory solution

Compare your reasoning with the worked solution

D1 has the stated end-to-end evidence for that tested moment. D2 needs a current check-in/evaluation and access test; enrollment alone is insufficient. D3 is an assignment-scope issue, not necessarily a failed policy setting. D4’s older compliance result does not establish current connectivity or access; separate the transport failure from compliance interpretation. Report unknown and not-in-scope distinctly. Do not mark every non-success as noncompliant or widen assignment to all devices just to make a dashboard look complete.

Official reference for further study

Workbook already downloaded

Write the pilot release note

Build your project

Write a four-device triage board with next action, owner and evidence. Add a pilot acceptance matrix covering enrollment, assignment, delivery, compliance and a resource access test.

What a complete result looks like

The board separates management and access states

A passes only the stated checks. B needs current check-in and delivery evidence, C needs the conflicting setting and assignments, and D needs enrollment prerequisites. The pilot matrix tests each management layer plus the actual resource transaction. A compliant device can still lack a user’s application permission, so do not repair an access denial with blanket compliance exclusions.

Acceptance criteria

  • Management states distinguished
  • Effective targeting checked
  • Pilot impact and recovery included
  • No unverified tenant rollout

Self-review record

Record your inputs, expected and actual outputs, failing test, correction, and remaining limitation. A reviewer should be able to reproduce your conclusion from your evidence. Compare your result with the lab baseline; explain any deliberate extension rather than simply copying its output.

Retrieval practice

Answer in your own words before opening each explanation. Use an example from the fixture to justify your answer.

Does enrollment prove configuration applied?

Compare your reasoning

No.

What should accompany compliance status?

Compare your reasoning

Evaluation time, relevant policy and requirement details.

Does compliance alone grant application access?

Compare your reasoning

No.

Write the pilot release note

Include platform applicability, assignment population, delivery freshness, setting outcomes, conflicts, business tests and rollback owner. State the sample size and exceptions. Keep “not applicable,” “not yet observed,” “error” and “noncompliant” distinct when the platform supplies different states.

A successful pilot is a reasoned basis for controlled expansion, not proof that every future endpoint will behave identically. Use current Intune documentation when implementing; portal paths, setting applicability and licence requirements can change. This course's evidence exercise requires no tenant or paid device enrollment.

Transfer project — changed conditions

Create a pilot acceptance matrix with intended scope, actual assignment, last observation, policy result, app result and next owner. Add a deliberately noncompliant device to test the expected denied route where the approved access design requires it. Include recovery for a legitimate blocked user and a rollback boundary. Cloud execution remains a separate authorized lab exercise; label the supplied matrix as tabletop evidence.

Practical assessment rubric

Score each dimension 0–2: 0 = absent or materially incorrect; 1 = partly correct with an unresolved gap; 2 = correct, explicit and supported by the supplied evidence or an actual labeled lab result.

  1. Evidence/model: identify the relevant entities, inputs, assumptions and boundaries without inventing facts.
  2. Main result: derive the case-specific expected result, calculation or decision and show the intermediate reasoning.
  3. Failure/boundary: test the changed condition and explain why the original conclusion does or does not transfer.
  4. Verification: supply reproducible steps and expected/observed results; label manual traces as manual, not executed.
  5. Communication/safety: explain limitations, owners and a proportionate next action without unsafe or unnecessary access.

Target: at least 8/10, with no zero in main result or communication/safety. This is a local learning rubric, not an accredited certification standard. A written/manual solution demonstrates reasoning only; operational competence additionally requires the relevant executable lab in an authorized environment. The native multiple-choice score is separate and does not automatically grade this rubric.

Submission template

Remediation

If the main result is wrong, reconstruct the supplied case from the raw inputs before changing code or controls. If the boundary case is wrong, identify the assumption that changed and rerun both the original and changed case. If verification is missing, do not convert a prediction into an observed result. Reattempt the transfer task without copying the worked solution, then explain it to another person.

Official reference for further study

Assessment: explain your decisions

Choose an answer and write your reason before opening each explanation. Then explain why the other choices do not fit the evidence. Use missed questions to revisit the lesson. This knowledge check is only one part of assessment: complete the practical transfer project as well. It does not predict certification-exam success.

1. Does enrollment alone prove compliance?

  1. No
  2. Yes, for every requirement
  3. Only after renaming
Answer and explanation

No — Enrollment and evaluated compliance are different states.

2. What is evidence of policy delivery?

  1. Only assignment existence
  2. Device check-in and policy results
  3. The group’s display color
Answer and explanation

Device check-in and policy results — Operational results establish delivery/evaluation.

3. What should precede broad endpoint enforcement?

  1. No testing
  2. Unexplained exclusions
  3. A scoped pilot with recovery and evidence
Answer and explanation

A scoped pilot with recovery and evidence — A pilot checks behavior and business impact.

4. A device is enrolled but has not checked in since a policy was assigned. What remains unverified?

  1. Policy delivery and current setting result
  2. The fact that every policy applied
  3. Whether enrollment guarantees app access
Answer and explanation

Policy delivery and current setting result — Enrollment and delivery are different stages. Obtain current evidence before judging the setting’s effectiveness.

5. A compliant device receives an app access denial. What should be checked next?

  1. Assume compliant means universally authorized
  2. The user/request, applicable access evaluation and app entitlement
  3. Disable compliance for the entire fleet
Answer and explanation

The user/request, applicable access evaluation and app entitlement — Compliance supplies one signal, not every permission. The denial may be from a different access boundary.

6. A pilot device is outside the intended assignment group. What should happen before changing it?

  1. Re-enroll every pilot device
  2. Declare an Intune service outage
  3. Confirm intended scope and approval
Answer and explanation

Confirm intended scope and approval — The mismatch is a targeting question until evidence shows otherwise. Fleet-wide changes and outage claims are unsupported.

7. What is D3’s first diagnostic boundary?

  1. Assignment scope/filtering.
  2. A proven hardware failure.
  3. Successful policy evaluation.
Answer and explanation

Assignment scope/filtering. — The device is excluded before the policy is evaluated. Diagnose targeting before settings or enforcement.

8. Can D2 be counted as an end-to-end pass?

  1. Yes, because its name appears in inventory.
  2. No; current evaluation and access are unverified.
  3. Yes, because it is enrolled.
Answer and explanation

No; current evaluation and access are unverified. — The requirement includes current delivery/evaluation/access evidence, not merely management enrollment.

9. What does D4’s connectivity loss prove about compliance?

  1. The device is certainly compliant forever.
  2. The device must be noncompliant.
  3. Nothing definitive about current compliance by itself.
Answer and explanation

Nothing definitive about current compliance by itself. — Network reachability and policy compliance are distinct states. An old result cannot settle the current end-to-end outcome.

Use the explained questions above for offline practice. A scored attempt requires the course assessment on CogniSkill.ca.