Microsoft MD-102 Endpoint Administrator Study Plan: How to Organize Preparation From First Review to Final Practice

 

A strong MD-102 study plan should behave like an endpoint-management program, not like a reading list. The exam is built around decisions that happen across a device lifecycle: establish identity and enrollment, deploy and configure the device, protect it, deliver and secure applications, then monitor and improve operations. If your preparation follows that same lifecycle, facts become easier to retrieve because they are attached to a sequence of causes, controls, and evidence.

Microsoft’s current MD-102 skills outline is the version measured from July 24, 2026. It weights Prepare infrastructure for devices at 20–25%, Manage and maintain devices at 25–30%, Protect devices at 15–20%, Manage and secure applications at 15–20%, and Optimize endpoint operations by using automation, monitoring, and reporting at 10–15%. The July 2026 update matters because it expanded enrollment detail, changed parts of cloud-based Windows deployment and remote actions, strengthened endpoint-security coverage, and added a new automation, monitoring, and reporting domain. A preparation plan built around an older four-domain outline can therefore leave a real gap.

The practical goal is not to assign exactly 25% of your calendar to a 25% domain. Weight tells you how much representation a domain may have on the exam; it does not tell you how long you personally need. Someone who administers Intune every day may move quickly through enrollment and configuration but need deliberate work on Graph automation or Intune Suite capabilities. Someone from traditional imaging and Group Policy may know Windows deeply yet need more time on Autopilot, cloud identity, mobile enrollment, compliance, and app protection. Your plan should react to evidence rather than treat every candidate as identical.

Begin with a blueprint-and-baseline session before you schedule weeks

The first study session should answer two questions: what does the active exam expect, and where are your actual gaps? Start by reading the current skills outline from top to bottom without trying to memorize every bullet. Mark objectives as familiar, partially familiar, or unfamiliar. Then separate familiarity from operational ability. Recognizing the phrase ‘Windows Autopilot’ is not the same as being able to choose a deployment mode, explain prerequisites, predict user experience, and troubleshoot a failed enrollment.

Use the current MD-102 objectives breakdown as the mapping layer between the Microsoft objective language and the practical mechanisms you need to understand. The purpose of that mapping is not to add another checklist. It is to identify the dependency behind each objective. If you are weak on compliance, for example, the dependency may be that you do not clearly separate device compliance evaluation from a Conditional Access access decision. If you are weak on application protection, the dependency may be that you still treat MAM and device management as the same control boundary.

After the blueprint review, take a short diagnostic using scenario-style questions or your own written prompts. Do not use the score as a pass prediction. Tag each miss by domain and by error type: knowledge gap, architecture gap, sequence gap, troubleshooting gap, or configuration-detail gap. A knowledge gap means you genuinely do not know what a capability does. An architecture gap means you know the pieces but cannot decide how they fit together. A sequence gap means you perform the right actions in the wrong order. A troubleshooting gap means you jump to a fix without using available evidence. A configuration-detail gap means the concept is sound but a platform-specific control, assignment, or prerequisite is missing.

The baseline is complete when it changes your calendar. If the diagnostic shows that you already understand Windows deployment but repeatedly confuse enrollment boundaries across Android, Apple, and BYOD scenarios, shift time toward enrollment. If endpoint security is familiar but you cannot explain how EDR integration, antivirus policy, attack-surface-reduction rules, App Control for Business, and security baselines differ, create a focused protection block. The point of a baseline is to prevent equal-time studying from hiding unequal weaknesses.

Organize the plan in five learning blocks that mirror the current role

A useful default sequence is infrastructure first, device management second, protection third, applications fourth, and operations fifth. That sequence follows dependencies. You cannot reason well about compliance-based access until device identity and enrollment make sense. You cannot troubleshoot application delivery until you understand assignment scope and device state. You cannot interpret operational analytics until you know what healthy deployment, policy, security, and application behavior should look like.

Do not make the blocks completely isolated. Each block should end with an integration exercise that pulls earlier material forward. When you study device configuration, include an assignment decision that depends on Entra groups or enrollment-time grouping. When you study protection, require the device to be enrolled, configured, and compliant before security policy is evaluated. When you study applications, add Conditional Access or app-protection requirements. When you reach monitoring, use failures created in all four earlier blocks. This produces spaced retrieval automatically.

Block 1: prepare infrastructure for devices by learning the entry conditions

The infrastructure block should build a mental model of how a device becomes identifiable, manageable, compliant, and eligible for access. Start with Microsoft Entra device identity. Compare registration and join in terms of ownership, identity relationship, management expectations, and user experience. Then move to device groups, including why dynamic membership rules are useful and what happens when assignment scope does not match the intended device population.

Next study Intune enrollment by platform and ownership model. The current blueprint expects more than Windows automatic enrollment. Build a matrix for Windows, macOS, iOS/iPadOS, and Android. For each platform, record whether the scenario is corporate-owned or personal, which enrollment path fits, which external ecosystem may participate, what restrictions apply, and what evidence you would check after failure. Include Apple Business Manager for corporate Apple enrollment, Android Enterprise modes, Samsung Knox Mobile Enrollment or Google zero-touch where relevant, and the difference between a device that is merely known to Entra and one that is properly enrolled into Intune.

A good infrastructure lab deliberately breaks enrollment. Change one prerequisite at a time: remove a user from the intended automatic-enrollment scope, apply an enrollment restriction, use an incompatible ownership path, or misalign a group assignment. Before fixing it, predict the symptom. Then verify the actual state in Intune and Entra. This turns enrollment from memorized wizard steps into dependency reasoning.

Finish the block with identity and compliance. Separate four layers: administrative permission, device compliance, authentication, and access decision. Intune roles and scope tags control what administrators can manage. Compliance policies evaluate whether devices meet defined requirements. Windows Hello for Business changes how users authenticate. Conditional Access consumes signals such as compliance and applies access policy. Windows LAPS and local-group management address local privilege. Multi-admin approval adds separation of duties for sensitive administrative operations. When a scenario includes several of these controls, ask which layer is actually failing rather than selecting the control with the strongest security-sounding name.

Your exit test for Block 1 should be a blank-page design exercise: given a company with corporate Windows laptops, personal mobile devices, regional help desks, and a requirement that only compliant devices access selected resources, sketch identity, enrollment, administrative scope, compliance, and access flow. If you can explain what happens from first sign-in to policy enforcement and name the evidence you would inspect when enrollment or access fails, the block is ready for maintenance review rather than more first-pass reading.

Block 2: manage and maintain devices with deployment, configuration, and remote evidence

This is the largest current domain, so give it enough practical depth. Begin with Windows deployment and upgrade choices. Learn to distinguish Windows Autopilot deployment profiles from newer device-preparation policies and understand the purpose of user-driven, pre-provisioning, and self-deploying modes. The exam can present a business constraint—shared device, end-user setup, technician staging, minimal touch—and expect you to map that requirement to a deployment approach.

Treat Enrollment Status Page as an experience and dependency control, not as a page you memorize. Ask which required policies and applications must complete before the user proceeds, what a timeout or failure means, and how a blocking configuration affects first-use experience. Then connect deployment with naming, group targeting, Windows 11 upgrade planning, and Windows 365 Cloud PC provisioning. The current blueprint also includes Windows Backup and Restore through Intune, so recovery expectations belong in the same lifecycle rather than in an unrelated final-week fact list.

The device-configuration portion should be studied through policy intent. Create examples for Windows, Android, iOS/iPadOS, macOS, and specialty devices. For Windows, include Settings Catalog or configuration profile decisions, ADMX import where appropriate, and Group Policy analytics when an organization is translating older management into modern policy. Then test targeting with assignment filters and enrollment-time grouping. A policy that is technically correct but assigned to the wrong population is an operational failure, and exam scenarios often reward that distinction.

Dedicate a focused sub-block to Intune Suite capabilities because they are easy to skim and easy to confuse. Endpoint Privilege Management addresses controlled elevation rather than simply granting permanent local administrator rights. Enterprise App Catalog supports application management. Remote Help provides assisted support. Microsoft Cloud PKI concerns cloud-based certificate issuance and health. Microsoft Tunnel for Mobile Application Management extends protected connectivity to app-managed scenarios. Advanced Analytics adds insight such as anomaly detection and risk-oriented recommendations. For each capability, write one sentence that begins, ‘Use this when the requirement is…’ and one that begins, ‘Do not choose this when the real requirement is…’ Those two sentences are better preparation than memorizing marketing descriptions.

Finish Block 2 with remote actions and diagnostics. The blueprint includes sync, restart, retire, wipe, bulk actions, Defender security-intelligence updates, BitLocker key rotation, local administrator password rotation, device queries using KQL, and diagnostic collection. Study the operational risk of each action. Retire and wipe are not synonyms. A sync request is not proof that the endpoint received and applied a policy. Rotating a recovery key is different from verifying encryption state. A device query can answer a state question but does not automatically remediate it. Collecting diagnostics is useful only if you know what evidence you expect to find.

Your Block 2 capstone should be a deployment-to-support scenario. Start with a new Windows device, choose a provisioning path, apply configuration, deliver required apps, then inject a failure such as a missing assignment, a blocked Enrollment Status Page dependency, or an incorrect filter. Require yourself to identify the failure from state and logs before changing configuration. That sequence mirrors the role more closely than clicking through unrelated portal pages.

Block 3: protect devices by reasoning from threat, control, and update state

Endpoint protection study should begin with the threat or policy objective, not with the product menu. Antivirus policy, firewall policy, disk encryption, attack-surface-reduction rules, security baselines, EDR integration, App Control for Business, and Defender onboarding address different parts of the risk model. Build comparison tables around purpose, prerequisite, target, evidence, and common failure rather than trying to rank controls from weak to strong.

Encryption is a good example. A strong answer distinguishes configuring a BitLocker policy, checking whether encryption has actually completed, recovering or rotating a recovery key, allowing user self-service recovery where appropriate, and investigating why a device is noncompliant. One setting does not prove the entire lifecycle. The same principle applies to EDR: integrating Intune with Microsoft Defender for Endpoint, onboarding a device, assigning an EDR policy, investigating a threat, and triaging an incident are related but distinct activities.

Attack-surface reduction deserves scenario practice because the trade-off is often operational. A rule can reduce exposure and still create compatibility issues for a legitimate workflow. The exam may expect the least disruptive control that satisfies a requirement, a staged deployment, or evidence before broader enforcement. Practice explaining why a policy should be piloted, what telemetry should be reviewed, and what fallback exists if the control breaks a business process. That is more durable than memorizing a switch state.

Then study updates as an availability-and-risk problem. Compare update rings, feature updates, quality updates, Windows Autopatch, Hotpatch policies, Delivery Optimization, and platform-specific update controls. Ask which requirement each solves: cadence, deferral, version targeting, bandwidth efficiency, accelerated security response, or staged deployment. Include iOS/iPadOS, macOS, and Android because the role is explicitly multi-platform. Monitor update state rather than assuming that assignment equals success.

For the protection capstone, create a small incident narrative. A group of devices is encrypted but marked noncompliant; another group has an endpoint-security policy assigned but is not sending expected EDR evidence; a third is missing a quality update. Decide which console state or report you would inspect first, which policy owns the condition, and which action is safe. The objective is to choose the next useful evidence, not to make the fastest possible change.

Block 4: manage and secure applications by separating deployment from data protection

Application questions become easier when you separate three ideas: installing software, configuring software, and protecting organizational data inside software. Deployment uses Intune app-management mechanisms such as Win32 apps, line-of-business apps, Microsoft Store apps, Microsoft 365 Apps, and platform-specific stores. Configuration can use app configuration or Office policy mechanisms. Protection can use app-protection policies and Conditional Access. One application can involve all three layers, but a requirement normally emphasizes one.

Build a deployment exercise around detection, requirements, dependencies, assignment, and monitoring. If a Win32 app does not install, do not begin by rebuilding the package. Check whether the device or user is actually in scope, whether requirements are met, whether dependencies succeeded, whether detection logic is correct, and what the installation status reports. A package that installs manually but fails through Intune often points toward deployment context or detection rather than application binaries.

For Microsoft 365 Apps, connect deployment choice to lifecycle. You may deploy through Intune, use the Office Deployment Tool as part of an Autopilot process, or manage policy through Intune or the Microsoft 365 Apps admin center. Avoid treating these as competing products. They are management surfaces that fit different administration patterns. Scenario questions often become straightforward once you identify whether the requirement is initial installation, policy enforcement, update control, or post-deployment monitoring.

App protection deserves its own lab because managed and unmanaged devices create different boundaries. On a BYOD device, the organization may need to protect corporate data inside a managed application without taking full device management. Practice the flow from app-protection policy to data-transfer restrictions, access requirements, and Conditional Access. Then compare that with a fully managed corporate device where configuration and compliance controls can operate at the device level. If you cannot explain why the organization would choose MAM without enrollment, keep working this block.

Your Block 4 capstone can be a mobile-workforce scenario: personal iOS and Android devices need Outlook and Teams access, corporate data must stay inside approved apps, and the company does not want full control of personal devices. Design the app-protection and access approach, then add a corporate Windows laptop that requires full app deployment and device compliance. The contrast forces you to choose the control boundary from ownership and privacy requirements rather than from habit.

Block 5: finish the first pass with automation, monitoring, and reporting

Do not leave the newest domain until the final evening simply because its weight is smaller. It tests whether you can operate endpoint management at scale. Begin with PowerShell and Microsoft Graph as automation interfaces. You do not need to turn preparation into a software-development course, but you should understand why repetitive tasks, reporting, and remediation benefit from automation, how authentication and permissions matter, and why a script should be tested safely before broad execution.

The current blueprint also includes extending device compliance with PowerShell and reviewing findings from Security Copilot agents in Intune. Study these as decision-support workflows rather than magic remediation. An agent may identify a threat, performance issue, or recommendation, but an administrator still needs to interpret scope, evidence, business impact, and the safety of a response. Treat generated recommendations the same way you treat any other operational signal: validate before you act.

Monitoring should connect reports to decisions. Endpoint Analytics can surface device health, startup performance, application reliability, and proactive-remediation opportunities. Intune reporting can be filtered, customized, exported, or represented through dashboards and workbooks. Tenant health and service communications matter when a symptom may come from the service rather than from your policy. Alerts for compliance drift, enrollment failure, or configuration conflict are useful only when the threshold and recipient support a real response process.

Build one proactive-remediation exercise. Define a detectable condition such as a service state, configuration drift, or common endpoint issue. Write or review a detection script, define the remediation, then decide how you will prove that the fix worked and how you will prevent repeated harm if the remediation is unsafe. The study value lies in the control loop: detect, evaluate, remediate, verify, and monitor recurrence.

For the operations capstone, use three devices with different symptoms and decide which evidence belongs to which layer. One fails enrollment, one is compliant but slow, and one has an application reliability problem. The correct monitoring path should differ. This teaches you to avoid a common weak habit: opening the same dashboard for every problem because it is familiar.

Use a weekly rhythm that alternates learning, doing, and retrieval

A study plan becomes effective when the weekly rhythm prevents passive reading from dominating. A practical pattern is: concept session, hands-on session, scenario session, spaced review, then integration. The exact number of days is flexible. The important part is that every topic is retrieved after a delay and applied in a different form. Reading Intune enrollment documentation on Monday and rereading the same notes on Tuesday feels fluent but provides weak evidence that you can solve a scenario on Friday.

For each major topic, create a four-column study record: requirement, control, verification, failure mode. Requirement states the business or technical need. Control states what you would configure or choose. Verification states what proves success. Failure mode states what can break even if the configuration looks reasonable. For Autopilot, verification might include registration, profile assignment, Enrollment Status Page behavior, and successful first-use state. For compliance, verification includes policy state and the downstream access result. For app deployment, verification includes assignment, installation status, detection, and user/device context.

Use short retrieval drills for details that genuinely require recall—platform names, policy categories, feature distinctions—but reserve longer sessions for architecture and troubleshooting. You should spend more time explaining why two similar options differ than reciting a definition. If a prompt asks you to choose between wipe and retire, your answer should include ownership, desired data removal, and the intended post-action state. If a prompt asks you to choose between app protection and device compliance, your answer should identify the control boundary and what information each mechanism can evaluate.

One useful scheduling rule is to stop a study block when your errors have become specific. ‘I do not understand Intune’ is too broad. ‘I confuse assignment filters with dynamic Entra group membership when targeting an app’ is specific enough to remediate. ‘I know update rings but cannot explain when feature-update policy should be separated from quality-update cadence’ is specific. Your calendar should keep narrowing broad uncertainty into explicit distinctions.

Make hands-on work small enough to repeat and rich enough to fail

A lab does not need a production-sized tenant to be valuable. Small, repeatable exercises are better for exam preparation because you can change one variable and observe the effect. Create one or two test users, a small group structure, representative device records, a few policies, and a controlled application. Document the intended state before making changes. Then deliberately create a failure and see whether your troubleshooting process finds it.

Good failure injections include removing a device from assignment scope, changing an enrollment restriction, setting incompatible requirements, using a detection rule that does not match the installed state, blocking a required app during provisioning, creating conflicting configuration, or altering a compliance condition. The point is not to build chaos. It is to learn which evidence changes when one dependency breaks.

Keep a lab journal with five short fields: intended state, configuration choice, expected evidence, observed evidence, and explanation. If the observed evidence differs, add the root cause and safe corrective action. This format turns a GUI exercise into a reusable reasoning artifact. Near the exam, you can hide the configuration choice and try to reconstruct it from requirement and evidence.

Use this earlier MD-102 preparation overview when you need a broader orientation to endpoint-administration preparation, but keep the current July 2026 blueprint beside your notes because product and exam scope change. Older explanations can still teach durable concepts, yet your final priority decisions should follow the active objective set.

Add a troubleshooting method that works across every domain

MD-102 scenarios often become difficult because multiple controls touch the same device. Use a consistent troubleshooting sequence: define the intended state, identify the current state, confirm scope and assignment, verify prerequisites, inspect the most specific evidence, isolate the failing layer, make the smallest safe change, then prove the new state. This is slower than guessing once and faster than changing five settings without knowing which one mattered.

Scope comes early because a surprising number of endpoint problems are targeting problems. A policy can be perfectly configured and never apply. A user can have the right license but sit outside the enrollment scope. An app can be healthy but excluded by assignment. A device can meet a security control but fail access because Conditional Access evaluates a different signal. Check who and what the configuration is meant to affect before rewriting the configuration.

Prerequisites come next. Autopilot depends on device and profile state. Apple corporate enrollment depends on the relevant Apple integration. Android zero-touch or Knox enrollment depends on the ecosystem relationship. App deployment depends on platform, requirements, context, and detection. Cloud PKI depends on certificate architecture. EDR visibility depends on integration and onboarding. A missing prerequisite can make a later-stage control look broken even when it is correctly defined.

Evidence should be specific. ‘The portal shows a red icon’ is weak. ‘The device is in scope, enrollment succeeded, the compliance policy evaluated noncompliant because encryption state is missing, and Conditional Access denied access because compliant device is required’ is useful. Train yourself to narrate that chain. The exam does not give you unlimited logs, but the reasoning habit helps you use whatever evidence it does provide.

Run a midpoint review before you increase question volume

After the first complete pass through all five blocks, repeat the diagnostic. Compare error categories, not only percentage correct. If knowledge gaps fall but troubleshooting gaps remain, more reading is unlikely to solve the problem. If you can explain architecture but still miss platform-specific enrollment choices, targeted recall and hands-on comparison are appropriate. If you keep selecting destructive remote actions when a reversible action would meet the requirement, practice operational-risk decisions.

Build a weakness matrix with domain on one axis and error type on the other. A row might show that application management has no major knowledge gap but several sequence and troubleshooting gaps. Another might show that automation has a large knowledge gap but little evidence yet about troubleshooting. The matrix tells you what kind of study to schedule. Do not respond to every weak score with ‘do more questions.’ Sometimes the right response is a ten-minute lab; sometimes it is a comparison note; sometimes it is a deeper architecture explanation.

At this stage, practice questions become more useful because they can test discrimination rather than introduce the entire topic. Use them diagnostically. For every wrong answer, record why your chosen option was tempting, which clue should have changed your decision, and what rule transfers to a new scenario. Avoid memorizing the wording of a question. The objective is to make your next decision better when the names, order, and constraints change.

Use the final preparation phase to integrate rather than relearn

The final phase should not be a compressed second first-pass. Reduce broad reading and increase mixed scenarios, targeted remediation, retrieval, and operational walkthroughs. Revisit your lab journal and weakness matrix. Focus on unresolved distinctions: join versus register, compliance versus access decision, device management versus app protection, required versus available app assignment, retire versus wipe, configuration versus verification, update policy versus update evidence, detection versus remediation, and alert versus root cause.

Run several end-to-end narratives. Example: a new corporate Windows device must be pre-provisioned, receive a required security baseline and Microsoft 365 Apps, become compliant, access a protected resource, report into Defender, receive updates, and appear healthy in Endpoint Analytics. Now break one part at a time. Another narrative can use a personal mobile device that should remain unmanaged at the device level but needs protected corporate applications. A third can use a Windows 365 Cloud PC with provisioning and policy requirements. These stories force multiple domains to coexist without turning review into random trivia.

Keep version awareness in the final checklist. The active English-language MD-102 skills outline is the July 24, 2026 version, and Microsoft notes that localized exams can lag the English update by roughly eight weeks. If you are taking a localized exam or your appointment is near a blueprint change, confirm the skills outline associated with your scheduled version instead of assuming that every study resource is synchronized. Mark the blueprint date in your notes so outdated material is easier to identify.

Use the exam’s scoring requirement as context, not as a study target. Microsoft states that a score of 700 or greater is required to pass, but a raw practice percentage does not translate directly into that scaled score. Your readiness evidence should therefore be broader: repeated success on fresh mixed scenarios, fewer foundational errors, faster recognition of dependencies, the ability to explain why plausible alternatives are wrong, and a stable troubleshooting sequence under time pressure.

Define readiness with behaviors you can observe

You are closer to ready when you can take a requirement and choose the correct management boundary before thinking about a product screen. You can distinguish identity, enrollment, management, compliance, access, application protection, and endpoint security. You can explain what evidence proves a deployment or policy worked. You can predict the likely symptom of a broken prerequisite. You can choose reversible troubleshooting steps before destructive ones. You can describe how monitoring closes the loop after deployment.

You are not ready merely because you have read every objective once or because the Intune portal looks familiar. Warning signs include relying on menu location instead of concept, treating assignment as proof of application, confusing policy state with access state, memorizing one Autopilot path for every device scenario, assuming all mobile management requires full enrollment, treating Defender integration as equivalent to successful onboarding, or reading every operational alert as a reason to change configuration immediately.

A final readiness session should include explanation without notes. Pick ten blueprint objectives at random and answer four prompts for each: what business problem does this address, what prerequisite matters, what evidence proves success, and what similar control could be confused with it? If your answers are precise and scenario-based, you are retrieving the structure of the role rather than isolated terms.

A flexible schedule is better than an arbitrary calendar promise

Candidates often ask whether MD-102 requires two weeks, six weeks, or three months. Calendar length depends on starting experience, lab access, available hours, and how much of the modern Microsoft endpoint stack you already operate. A better plan uses exit criteria for each block. Move forward when you can explain and apply the block, then keep it alive through spaced review. Return when diagnostics show regression.

For a candidate with substantial Intune and Entra experience, the first pass may be brief and the largest investment may go to newer blueprint areas such as Intune Suite capabilities, multi-platform details, Security Copilot-related workflows, Graph automation, proactive remediation, and current update-management features. For a candidate from traditional on-premises endpoint administration, more time may be needed on cloud identity, Autopilot, mobile enrollment, Conditional Access, app protection, and service-based monitoring. For a newer administrator, fundamentals such as identity scope, device ownership, security boundaries, application deployment logic, and troubleshooting discipline may need to be built before timed practice becomes useful.

The plan should get more individualized over time. Early sessions are blueprint-driven because you need complete coverage. Middle sessions are evidence-driven because diagnostics reveal your weaknesses. Final sessions are risk-driven because you are deciding which remaining gaps can still change performance. This progression prevents both common extremes: spending weeks polishing comfortable topics and panic-reading unfamiliar features at the end.

The study plan should leave you with a reusable endpoint-management model

MD-102 preparation is strongest when the exam becomes a forcing function for better operational reasoning. A device enters identity and management, receives configuration and applications, proves compliance, gains or loses access, receives security controls and updates, generates telemetry, and is remediated when state drifts. That lifecycle is useful beyond the test because it is how modern endpoint administration actually behaves.

Build your first pass around the current five domains, but let diagnostics control the amount of time. Use small labs with deliberate failure, record evidence, revisit earlier domains through integration scenarios, and make every wrong answer produce a more specific correction rule. By the final phase, you should be doing less broad learning and more precise retrieval, troubleshooting, and cross-domain decision making.

The most valuable outcome is not a stack of notes. It is the ability to look at an endpoint scenario and ask the right questions in the right order: What is the intended state? Who or what is in scope? Which prerequisite enables the control? Which layer owns the decision? What evidence proves the current state? What is the smallest safe action that changes it? If your study plan repeatedly trains those questions while keeping the July 2026 blueprint in view, final practice becomes confirmation of a working model rather than a last attempt to memorize the portal.