D-AXAZL-A-00 Exam Training Course Study Plan
D-AXAZL-A-00 Study Plan — Dell AX System for Azure Local Implementation Achievement
Over 4 weeks, you’ll build the D-AXAZL-A-00 implementation skills in the same order you would in a real project: Week 1 focuses on readiness and host build (prereqs + OS deployment), Week 2 locks in Azure Arc onboarding and governance triage, Week 3 executes Azure Portal deployments and teaches you to troubleshoot using portal feedback, and Week 4 shifts to ARM-template automation with end-to-end drills and final review across all exam domains and objectives.
Daily Workload
Daily target: 4 pomodoros (1 pomodoro = 25 minutes focused work + 5 minutes break).
Pomodoro 1–2: Learn & annotate (Base + Additional Content) into your own checklist/diagram.
Pomodoro 3: Do a mini-lab on paper (run sheet, parameter table, evidence pack) and verify with a self-check.
Pomodoro 4: Spaced review (flashcards + mistake log) and 5-minute “teach-back” summary.
Every 3rd day: do a 15-minute cumulative recap of prior days’ deliverables.
Week 1 — Foundations: Readiness and Host Build
Week 1 Theme
This week builds the “deployment foundation” you must get right before any Azure-driven deployment can succeed: consistent Dell AX node baselines, predictable networking and outbound connectivity, readiness validation with Environment Checker, and repeatable OS deployment using a Golden Image with verifiable post-imaging evidence and remote-management readiness.
Day 1 — Node & Switch Baseline Contract
Study Content
Identify Cluster Deployment Prerequisite Tasks — Describe the required network switch configurations and BIOS/IDRAC settings for Dell AX nodes
Additional Content focus: consistent-node baseline + consistent-switchport behavior + iDRAC recovery plane
Create a one-page “baseline contract” you can apply node-by-node and port-by-port
Tasks
Task 1: Read + extract the baseline contract (1 pomodoro)
Read the Base chapter section on prerequisites and the Additional Content on switch + BIOS/iDRAC baseline consistency.
Deliverable: a 10–15 line “Baseline Contract” note (nodes + iDRAC + switchports) saved as a single page.
Verification cue: you can explain why “one node different” causes intermittent failures and list the first two checks you’d run.
Task 2: Build a switchport checklist (1 pomodoro)
Draft a switchport checklist covering VLAN expectations, LACP/port-channel alignment intent, and MTU consistency.
Deliverable: a checklist with “expected” vs “observed” fields for each port.
Verification cue: you can map each checklist line to a plausible symptom (e.g., validation fails, intermittent disconnect).
Task 3: Build an iDRAC recovery mini-plan (1 pomodoro)
Write a short recovery plan describing how you would regain access if host networking changes lock you out.
Deliverable: a 6-step recovery procedure using iDRAC (what you’d check/what you’d do).
Verification cue: your plan includes at least one “proof” step (e.g., open remote console) before and after changes.
Task 4: Spaced review + teach-back (1 pomodoro)
Create 8 flashcards from today’s baseline contract (front: symptom; back: likely drift and first check).
Deliverable: flashcards + a 5-sentence teach-back summary.
Verification cue: you can answer at least 6/8 flashcards correctly without notes.
Day 2 — Outbound Connectivity & Firewall Allowlisting
Study Content
Identify Cluster Deployment Prerequisite Tasks — List the firewall rules and outbound endpoints necessary for Azure Local connectivity
Additional Content focus: DNS/time/HTTPS categories + proxy/TLS inspection considerations
Build a security-facing “connectivity ask” that avoids guesswork
Tasks
Task 1: Convert connectivity needs into categories (1 pomodoro)
Study the Base + Additional Content connectivity model (DNS, time sync, HTTPS, proxy/TLS inspection).
Deliverable: a one-page “Connectivity Categories” sheet with what to allow and what to test per category.
Verification cue: you can explain why a timeout is usually not an RBAC problem.
Task 2: Draft a firewall/proxy request (1 pomodoro)
Write a concise request for the security/network team that describes the required outbound behavior and validation steps.
Deliverable: a short request template (who/what/why + how to verify) that you can reuse.
Verification cue: the request includes at least one node-side test and a note about proxy/TLS inspection compatibility.
Task 3: Create a layered troubleshooting funnel (1 pomodoro)
Create a 4-question funnel: DNS → time → outbound HTTPS → authorization/governance.
Deliverable: a flowchart (text is fine) with “evidence to collect” at each step.
Verification cue: given a “cannot reach endpoint” symptom, you can choose the correct first evidence item.
Task 4: Spaced review + teach-back (1 pomodoro)
Add 8 flashcards on proxy/TLS inspection pitfalls, DNS/time dependencies, and first-step diagnostics.
Deliverable: flashcards + a 60-second teach-back script.
Verification cue: you can recite the funnel in order without looking.
Day 3 — Environment Checker as a Remediation Loop
Study Content
Identify Cluster Deployment Prerequisite Tasks — Explain how to assess environment readiness using the Environment Checker tool
Additional Content focus: Inventory.xml as evidence + hard/soft/false-positive buckets
Practice prioritizing fixes by dependency, not by report order
Tasks
Task 1: Build an “Inventory.xml evidence loop” checklist (1 pomodoro)
Study the Additional Content approach: save baseline results, fix one cause, rerun, compare.
Deliverable: a checklist with steps “run → bucket findings → pick dependency-first fix → rerun → archive evidence.”
Verification cue: you can explain why saving “before/after” artifacts speeds troubleshooting and escalation.
Task 2: Create a triage rubric (1 pomodoro)
Write a rubric that classifies findings into hard blockers, soft blockers/warnings, and environment caveats.
Deliverable: a rubric with a “what to do next” line for each bucket.
Verification cue: you can classify three example findings and justify the order you’d fix them.
Task 3: Build a dependency-first fix order (1 pomodoro)
Draft a standard remediation order: DNS/time → switch/host consistency → node baseline alignment → rerun checks.
Deliverable: a numbered remediation sequence with one “proof” check per step.
Verification cue: you can defend the sequence even if the report lists items in a different order.
Task 4: Spaced review + teach-back (1 pomodoro)
Make 10 flashcards that each pair a readiness failure pattern with “who owns the fix” (network vs platform).
Deliverable: flashcards + a 5-sentence teach-back summary.
Verification cue: you can answer at least 7/10 correctly without notes.
Day 4 — Golden Image as a Versioned Artifact
Study Content
Perform Operating System Deployment Tasks — Deploy the operating system using the Validated Solution Recipe (VSR) Golden Image
Additional Content focus: image versioning, acceptance gate, exception handling without drift
Practice the “compare evidence → reimage” decision pattern
Tasks
Task 1: Define your image versioning scheme (1 pomodoro)
Study the Additional Content “image lifecycle” approach and design a simple version label scheme.
Deliverable: a version label format + a short change log template for image updates.
Verification cue: you can explain how your scheme prevents “mystery drift” across nodes.
Task 2: Write an OS imaging acceptance gate (1 pomodoro)
Draft an acceptance gate that a node must pass before moving to Arc onboarding.
Deliverable: a 6–10 item acceptance checklist (what must be true, what evidence proves it).
Verification cue: your checklist includes at least one network and one remote-management check, not just “OS boots.”
Task 3: Create an exception playbook (1 pomodoro)
Write a playbook for “one node must be reimaged” and “one hotfix needed after imaging” without drifting the fleet.
Deliverable: a short playbook with “document → apply consistently → roll into next image” logic.
Verification cue: you can state when reimage is safer than incremental tweaks.
Task 4: Spaced review + teach-back (1 pomodoro)
Add 8 flashcards about drift symptoms and the deterministic remediation order (version → evidence diff → reimage).
Deliverable: flashcards + a 60-second teach-back.
Verification cue: you can explain the “weird one node” diagnosis path in under 30 seconds.
Day 5 — Post-Imaging Verification Evidence Pack
Study Content
Perform Operating System Deployment Tasks — Verify system contents post-imaging using PowerShell commands
Additional Content focus: minimal evidence pack (OS, NICs, disks, drivers, services) + per-node artifact structure
Learn how the evidence pack accelerates later troubleshooting
Tasks
Task 1: Define the five-bucket evidence pack (1 pomodoro)
Study the Additional Content verification buckets and tailor them to your environment assumptions.
Deliverable: a “5 buckets” checklist with the purpose of each bucket.
Verification cue: you can explain which bucket you’d check first for an Arc onboarding failure.
Task 2: Create a per-node folder structure (1 pomodoro)
Design the folder/file naming approach for collecting evidence per node (e.g., Node01\01_os.txt, 02_nics.txt…).
Deliverable: a folder naming plan you could hand to a teammate.
Verification cue: your plan makes it easy to diff Node04 vs Node01 by category.
Task 3: Build a comparison workflow (1 pomodoro)
Write a simple “compare failing node to known-good” workflow that starts from evidence packs.
Deliverable: a 7-step comparison workflow with “what conclusion you draw” at each step.
Verification cue: you can apply your workflow to a hypothetical “only Node04 fails” scenario without adding extra steps.
Task 4: Spaced review + teach-back (1 pomodoro)
Create 10 flashcards pairing a downstream symptom (portal validation fail, Arc timeout, remote management fail) with the evidence bucket to check first.
Deliverable: flashcards + a 5-sentence teach-back summary.
Verification cue: you can answer at least 7/10 correctly in 3 minutes.
Day 6 — Host Networking & Remote Management for Arc Readiness
Study Content
Perform Operating System Deployment Tasks — Configure host networking, remote access, and system settings using SConfig and PowerShell
Additional Content focus: layered “can ping but cannot proceed” map (DNS → HTTPS → remote management → governance)
Build a safe-change workflow that includes iDRAC fallback
Tasks
Task 1: Draft a safe-change workflow for networking (1 pomodoro)
Write a workflow for changing host networking that includes pre-check, change, and post-check steps.
Deliverable: a safe-change checklist with a required iDRAC “recovery ready” checkpoint.
Verification cue: your checklist includes a post-change remote management verification, not just ping.
Task 2: Build the “can ping but cannot proceed” decision map (1 pomodoro)
Study the Additional Content layered map and turn it into a quick decision tree.
Deliverable: a one-page decision tree with the first evidence step per layer.
Verification cue: you can route a “timeout” vs “forbidden” vs “DNS failure” symptom to the correct layer.
Task 3: Create an Arc-readiness pre-check list (1 pomodoro)
Draft a pre-check list that must be true before running Arc registration scripts (name resolution, time stability, outbound HTTPS, remote admin path).
Deliverable: an Arc-readiness checklist aligned to the layered map.
Verification cue: you can explain how each item prevents a specific onboarding failure class.
Task 4: Spaced review + teach-back (1 pomodoro)
Make 8 flashcards from today’s layered map and safe-change workflow.
Deliverable: flashcards + a 60-second teach-back summary.
Verification cue: you can recite the layer order and the first test per layer without notes.
Day 7 — Week 1 Integration Drill
Study Content
Combine Week 1 deliverables into a single “deployment foundation pack” (baseline contract + connectivity ask + readiness loop + imaging acceptance + evidence packs + Arc-readiness checklist)
Practice an end-to-end “first response” to a mixed failure scenario using only your artifacts
Identify your top 5 weak spots for Week 2 focus
Tasks
Task 1: Assemble the deployment foundation pack (1 pomodoro)
Collect all Week 1 deliverables into one folder (or notebook section) with a short index page.
Deliverable: an index listing each artifact and when to use it (baseline, connectivity, readiness, imaging, evidence, Arc-readiness).
Verification cue: you can find any artifact in under 30 seconds.
Task 2: Run a paper drill: “2 nodes succeed, 2 fail” (1 pomodoro)
Simulate a scenario where onboarding readiness is mixed and you must decide what to check first.
Deliverable: a written triage path (layered checks) plus the evidence you’d request at each step.
Verification cue: you start with scope/placement and connectivity primitives before RBAC/policy.
Task 3: Create a personal weak-spot list (1 pomodoro)
Review your notes and mark the top 5 concepts or steps you hesitate on (e.g., MTU vs VLAN symptoms, proxy/TLS inspection).
Deliverable: a prioritized list with one concrete action to improve each item in Week 2.
Verification cue: each weak spot has a measurable action (flashcards, rewrite checklist, redo drill).
Task 4: Spaced review + cumulative recap (1 pomodoro)
Do a cumulative review of all Week 1 flashcards and add 5 “integration” flashcards that connect multiple topics.
Deliverable: updated flashcards + a 5-minute written recap of Week 1 in your own words.
Verification cue: you can explain the Week 1 deployment sequence end-to-end without referencing notes.
Week 2 — Arc Onboarding and Governance Triage
Week 2 Theme
This week turns Azure Arc registration into a reliable, repeatable onboarding workflow: you’ll lock down scope mapping (tenant/subscription/resource group/location), build a per-node Arc evidence pack, practice handling partial success across nodes, and master a fast decision tree that separates network/proxy/DNS/time failures from RBAC, Azure Policy deny, and Conditional Access constraints—so you can choose the right “next best action” under exam pressure.
Day 1 — Scope Contract: Tenant, Subscription, Resource Group, Location
Study Content
Register Azure Local Machines with Azure Arc — Define and configure Azure subscription, tenant, and resource group variables for registration
Additional Content focus: scope banner + RG as governance boundary + location constraints
Build a “scope freeze” run sheet you can reuse for every onboarding session
Tasks
Task 1: Build a scope banner template (1 pomodoro)
Review the scope contract concepts (tenant/subscription/RG/location) and write a reusable “scope banner” block you will paste into every run sheet.
Deliverable: a scope banner template containing tenant, subscription, RG, and location fields with validation notes.
Verification cue: you can explain how scope drift causes “resources appear in the wrong place” symptoms.
Task 2: Create a resource group selection rubric (1 pomodoro)
Write a rubric for choosing the onboarding RG based on RBAC scope, policy scope, and operational ownership.
Deliverable: a 6–10 line rubric with “choose RG if…” and “avoid RG if…” rules.
Verification cue: you can name two ways RG choice changes success (permissions and policy).
Task 3: Map region/location constraints to failure symptoms (1 pomodoro)
Create a short mapping from “allowed locations policy” to likely validation/creation failures during onboarding.
Deliverable: a 1-page mapping table (constraint → symptom → first evidence to check).
Verification cue: given “deny due to location,” you choose inputs/policy evidence before touching node networking.
Task 4: Spaced review + teach-back (1 pomodoro)
Make 10 flashcards: front = scope mistake symptom; back = first verification step and fix.
Deliverable: flashcards + a 5-sentence teach-back on “scope freeze for the whole run.”
Verification cue: you answer at least 7/10 correctly without notes.
Day 2 — Execute Onboarding and Verify Placement + Connectivity Signals
Study Content
Register Azure Local Machines with Azure Arc — Execute the Azure Arc registration script and verify machine registration in the Azure portal
Additional Content focus: per-node Arc evidence pack + “healthy” portal signals
Practice verifying placement before troubleshooting deeper layers
Tasks
Task 1: Draft an Arc evidence pack checklist (1 pomodoro)
Write a checklist of what to capture from the registration run (command used, scope parameters, success/failure output, error text).
Deliverable: a per-node evidence pack checklist (script evidence + portal evidence).
Verification cue: you can describe what you’d compare between Node01 and Node04 when only one fails.
Task 2: Define “healthy in portal” signals (1 pomodoro)
Create a short list of portal checks: correct subscription/RG/location, visible machine object, and a basic connectivity/heartbeat indicator.
Deliverable: a “Portal Verification” checklist you can run in under 2 minutes per node.
Verification cue: you can explain why placement checks come before RBAC/policy changes.
Task 3: Build an idempotent rerun plan for partial success (1 pomodoro)
Write a rerun plan for “2 nodes succeed, 2 fail” that avoids drift: what to fix first, what not to change, and when to rerun.
Deliverable: a 7-step rerun plan with a single-hypothesis change rule.
Verification cue: your plan starts with scope/placement comparison, then moves to connectivity and governance layers.
Task 4: Spaced review + teach-back (1 pomodoro)
Add 8 flashcards about “placement vs health” and “why rerun after fixing root cause only.”
Deliverable: flashcards + a 60-second teach-back explaining the verification sequence.
Verification cue: you can recite the sequence: placement → connectivity signal → layer-specific evidence.
Day 3 — Network/Proxy/DNS/Time vs Authorization: First-Cut Classification
Study Content
Register Azure Local Machines with Azure Arc — Identify and resolve Azure policy or permission issues that may block registration
Additional Content focus: four-bucket decision tree (network/proxy, RBAC, Policy, Conditional Access)
Build an “error → bucket → first evidence” quick reference
Tasks
Task 1: Create an error-to-bucket quick reference (1 pomodoro)
Draft a one-page reference that maps common symptoms (timeout, TLS error, forbidden, deny, sign-in blocked) to the correct bucket.
Deliverable: an “error → bucket → first evidence” sheet.
Verification cue: you can route “timeout” to connectivity checks without considering RBAC first.
Task 2: Define evidence to collect per bucket (1 pomodoro)
For each bucket, list 3 evidence items to collect (node-side tests vs Azure-side logs/assignments).
Deliverable: a per-bucket evidence list you can use for escalation.
Verification cue: you can name the first evidence item for RBAC vs Policy without hesitation.
Task 3: Write the safest remediation order (1 pomodoro)
Write a remediation order that minimizes unnecessary change: scope → RBAC (least privilege) → compliant inputs → policy exception (if needed) → connectivity/proxy adjustments.
Deliverable: a numbered remediation order with a “stop condition” after each step.
Verification cue: you can explain why policy exceptions are last, not first.
Task 4: Spaced review + teach-back (1 pomodoro)
Create 10 flashcards where the back includes the “first best action” and “what not to do.”
Deliverable: flashcards + a 5-sentence teach-back on avoiding layer thrash.
Verification cue: you answer at least 7/10 correctly in under 4 minutes.
Day 4 — RBAC Deep Dive: Scope and Least Privilege
Study Content
Register Azure Local Machines with Azure Arc — Identify and resolve Azure policy or permission issues that may block registration
Focus: RBAC scope errors (right role, wrong scope) and least-privilege remediation habits
Practice diagnosing “forbidden” without over-granting permissions
Tasks
Task 1: Build a “right scope” RBAC checklist (1 pomodoro)
Write a checklist that forces you to confirm the target subscription/RG and where the role assignment actually applies.
Deliverable: a 6–10 item RBAC checklist with “target scope” and “assignment scope” fields.
Verification cue: you can explain how a role on RG-A fails when the script targets RG-B.
Task 2: Write a least-privilege remediation template (1 pomodoro)
Draft a template note you’d send to an admin: what role is needed, at what scope, and why.
Deliverable: a short request template specifying role + scope + verification step after assignment.
Verification cue: your template includes a post-change verification that onboarding can proceed.
Task 3: Simulate an RBAC failure triage (1 pomodoro)
On paper, walk through a “Forbidden” scenario and document the evidence and next actions in order.
Deliverable: a written triage path that ends with a rerun decision.
Verification cue: you collect scope/identity evidence before proposing policy or network changes.
Task 4: Spaced review + teach-back (1 pomodoro)
Add 8 flashcards about RBAC scope traps and least-privilege habits.
Deliverable: flashcards + a 60-second teach-back.
Verification cue: you can state “role + scope + verification” without notes.
Day 5 — Azure Policy Deny: Compliant Inputs First, Exceptions Last
Study Content
Register Azure Local Machines with Azure Arc — Identify and resolve Azure policy or permission issues that may block registration
Focus: policy deny patterns (allowed locations, required tags, restricted resource types)
Practice turning policy errors into compliant parameter choices
Tasks
Task 1: Build a policy-deny recognition checklist (1 pomodoro)
Write a checklist of “policy deny tells” and what to capture (assignment scope, requirement unmet, deny effect).
Deliverable: a policy-deny checklist with a minimum evidence set for escalation.
Verification cue: you can distinguish policy deny from RBAC deny based on evidence needs.
Task 2: Create a “compliant inputs” playbook (1 pomodoro)
Draft a playbook that fixes policy issues via compliant inputs first (region/tags), before requesting exceptions.
Deliverable: a short playbook with “try this first” steps and a decision point for exceptions.
Verification cue: you can explain why adding permissions doesn’t bypass a deny policy.
Task 3: Paper drill: tag requirement blocks onboarding (1 pomodoro)
Simulate a required-tags policy scenario and write the exact adjustments you would make and how you verify success.
Deliverable: a written remediation plan with an explicit rerun step and proof of compliance.
Verification cue: your plan includes a “before/after” evidence capture step.
Task 4: Spaced review + teach-back (1 pomodoro)
Create 10 flashcards on common policy constraints and the compliant-by-design approach.
Deliverable: flashcards + a 5-sentence teach-back.
Verification cue: you can describe the order: read deny → become compliant → rerun → only then exceptions.
Day 6 — Conditional Access and Identity Constraints: Recognize and Escalate Correctly
Study Content
Register Azure Local Machines with Azure Arc — Identify and resolve Azure policy or permission issues that may block registration
Focus: Conditional Access symptoms (interactive sign-in blocked, MFA requirements, device/location restrictions)
Practice creating an escalation packet that avoids vague “auth doesn’t work” reports
Tasks
Task 1: Build a Conditional Access symptom map (1 pomodoro)
Create a map from common sign-in/auth symptoms to likely Conditional Access involvement and the right evidence request.
Deliverable: a symptom map plus a list of “what to ask for” (sign-in log outcomes, CA results).
Verification cue: you can identify when the issue is identity policy, not networking or RBAC.
Task 2: Draft an escalation packet template (1 pomodoro)
Write a template for escalating identity constraints to the Azure/identity team: include scope banner, identity type, and observed error text.
Deliverable: an escalation template that can be filled in within 5 minutes during an incident.
Verification cue: your template includes at least one concrete log/evidence request.
Task 3: Paper drill: onboarding blocked by sign-in requirements (1 pomodoro)
Simulate a scenario where onboarding fails due to sign-in constraints and write the triage steps and escalation path.
Deliverable: a step-by-step triage note that avoids changing node config unnecessarily.
Verification cue: your steps include “do not modify firewall/proxy until identity constraints are ruled out.”
Task 4: Spaced review + teach-back (1 pomodoro)
Add 8 flashcards on CA vs RBAC vs Policy distinctions.
Deliverable: flashcards + a 60-second teach-back.
Verification cue: you can route “sign-in blocked” to identity evidence immediately.
Day 7 — Week 2 Integration Drill: Mixed-Failure Triage and Rerun Strategy
Study Content
Integrate: scope banner + Arc evidence pack + four-bucket decision tree + remediation order
Practice answering “What do you check first?” with evidence-based reasoning
Produce a single-page “Arc onboarding playbook” for Week 3 portal deployment readiness
Tasks
Task 1: Assemble the Arc onboarding playbook (1 pomodoro)
Combine your scope banner, portal verification checklist, evidence pack checklist, and decision tree into one 1-page playbook.
Deliverable: a single-page Arc Onboarding Playbook with section headers and a short index.
Verification cue: you can use it to triage any onboarding issue in under 2 minutes.
Task 2: Run a 3-scenario paper drill (1 pomodoro)
Scenario 1: timeout; Scenario 2: forbidden; Scenario 3: deny due to location/tags—write the first 3 actions for each.
Deliverable: a 3-scenario triage worksheet with actions and evidence items.
Verification cue: each scenario starts in the correct bucket and uses the correct first evidence.
Task 3: Define a “safe rerun” rule set (1 pomodoro)
Write rules for reruns: one hypothesis per rerun, document change, verify scope banner, and compare evidence packs.
Deliverable: a rerun rule set you can apply consistently across nodes and days.
Verification cue: your rules prevent multi-change thrash and preserve comparability.
Task 4: Spaced review + cumulative recap (1 pomodoro)
Do a cumulative review of Week 2 flashcards and add 6 “integration” cards that combine buckets + remediation order.
Deliverable: updated flashcards + a 5-minute written recap of Week 2.
Verification cue: you can explain the four buckets and the safest remediation order without notes.
Week 3 — Portal Deployment Execution and Feedback Triage
Week 3 Theme
This week trains you to deploy Azure Local through the Azure Portal with disciplined scope control and fast, evidence-driven troubleshooting: you’ll build a portal run sheet, choose compliant parameters (cluster name, resource group, region, tags), learn to separate validation blocks from execution failures, and practice turning portal feedback into a phase-based triage path with a minimum “escalation kit” you can produce quickly.
Day 1 — Portal Run Sheet and Scope Control
Study Content
Deploy an Azure Local Instance Using Azure Portal — Navigate the Azure Portal deployment wizard for Azure Local clusters
Additional Content focus: portal wizard as change control; scope banner + placement banner
Build a run sheet you can complete before clicking Create
Tasks
Task 1: Build the Portal Run Sheet v1 (1 pomodoro)
Review the portal-wizard Additional Content and extract the “scope banner / placement banner / identity / input snapshot” fields.
Deliverable: a one-page Portal Run Sheet template with blank fields and a short “double-check here” note for each field.
Verification cue: you can point to exactly where scope drift would happen and how your run sheet prevents it.
Task 2: Write a “scope drift recovery” checklist (1 pomodoro)
Draft a checklist for what to do if you can’t find deployed resources afterward (search by deployment name, verify subscription/RG, verify region).
Deliverable: a 6–10 step checklist that starts with scope verification before any node-side changes.
Verification cue: you can explain why “can’t find it” is usually not a node problem.
Task 3: Create a 2-minute pre-Create ritual (1 pomodoro)
Write a short ritual you will perform before clicking Create: confirm tenant/subscription, confirm RG, confirm region, confirm cluster name spelling.
Deliverable: a 4-line “Pre-Create Ritual” card you can paste at the top of every deployment note.
Verification cue: you can recite the ritual without looking and it includes both scope and placement checks.
Task 4: Spaced review + teach-back (1 pomodoro)
Create 8 flashcards pairing a portal mistake (wrong RG/region) with the quickest detection method (run sheet field + portal search).
Deliverable: flashcards + a 60-second teach-back explaining why portal deployments need “evidence first.”
Verification cue: you answer at least 6/8 correctly without notes.
Day 2 — Compliant Parameter Choices: Cluster Name, Resource Group, Region, Tags
Study Content
Deploy an Azure Local Instance Using Azure Portal — Input required configuration parameters such as cluster name, resource group, and region
Additional Content focus: RG as policy/RBAC boundary; region/location constraints; naming as operational identity
Practice turning governance constraints into parameter decisions
Tasks
Task 1: Create a naming convention rule set (1 pomodoro)
Write a rule set for cluster naming that encodes environment/site and avoids collisions.
Deliverable: a naming standard with 5–7 rules and 3 example names (dev/test/prod pattern).
Verification cue: you can explain how naming reduces “wrong environment” operational mistakes.
Task 2: Build an RG decision rubric (1 pomodoro)
Create a rubric for RG selection: permissions certainty, policy constraints, lifecycle ownership, and audit expectations.
Deliverable: a rubric with “preferred RG traits” and “avoid RG traits,” plus a short checklist you can run in 1 minute.
Verification cue: you can justify why the same deployment can succeed in RG-A but fail in RG-B.
Task 3: Map region/tags constraints to likely portal validation errors (1 pomodoro)
Write a mapping from allowed locations / required tags policies to the validation symptoms you’d expect to see.
Deliverable: a “constraint → symptom → compliant input fix” table (text is fine).
Verification cue: given a policy-like deny, you choose compliant inputs before requesting permission changes.
Task 4: Spaced review + teach-back (1 pomodoro)
Add 10 flashcards on parameter choices and governance interactions (RG, region, tags).
Deliverable: flashcards + a 5-sentence teach-back: “compliant-by-design beats exception-by-default.”
Verification cue: you answer at least 7/10 correctly in under 4 minutes.
Day 3 — Failure Phase Recognition: Validation vs Execution vs Post-Deploy
Study Content
Deploy an Azure Local Instance Using Azure Portal — Validate deployment success and troubleshoot common issues using portal feedback
Additional Content focus: phase-based triage model (validation, execution, post-deploy inconsistency)
Build a phase classifier you can apply to any portal message
Tasks
Task 1: Create a phase classifier card (1 pomodoro)
Summarize the three phases and what each phase implies about likely root-cause buckets.
Deliverable: a one-page Phase Classifier card with “Phase → likely causes → first best action.”
Verification cue: you can classify a sample error as validation vs execution within 15 seconds.
Task 2: Write a “validation failure” remediation order (1 pomodoro)
Draft a remediation order for validation failures: compliant inputs (region/tags) → RBAC scope → prerequisite completeness → rerun.
Deliverable: a numbered remediation order with a stop condition after each step.
Verification cue: your order avoids changing node networking when the portal is blocking you before deployment starts.
Task 3: Write an “execution failure” first-step method (1 pomodoro)
Create a method to identify the first failing step in the deployment timeline and route it to a cause bucket (governance vs readiness vs connectivity).
Deliverable: a 6-step “first failing step” method you can follow consistently.
Verification cue: you can explain why the first failing step matters more than the final summary.
Task 4: Spaced review + teach-back (1 pomodoro)
Create 8 flashcards that each start with a portal symptom and end with “phase + first evidence to collect.”
Deliverable: flashcards + a 60-second teach-back of your phase classifier.
Verification cue: you answer at least 6/8 correctly without notes.
Day 4 — Portal Evidence Kit and Escalation-Ready Notes
Study Content
Deploy an Azure Local Instance Using Azure Portal — Validate deployment success and troubleshoot common issues using portal feedback
Additional Content focus: minimum escalation kit (deployment name, timestamp, RG, first failing step, full error text, correlation ID)
Practice writing short, high-signal incident notes
Tasks
Task 1: Build a “Minimum Escalation Kit” template (1 pomodoro)
Create a template that forces you to capture the essential portal evidence items in a consistent order.
Deliverable: an escalation kit template with labeled fields and a short instruction line for where to find each in the portal.
Verification cue: you can fill the template in under 3 minutes from a hypothetical error screenshot description.
Task 2: Practice writing a 10-line failure report (1 pomodoro)
Write a concise failure report from a simulated portal failure (pick any: policy deny, forbidden, timeout, missing prerequisite).
Deliverable: a 10-line report that includes scope + phase + first failing step + proposed next action.
Verification cue: your report enables a teammate to reproduce the first check without asking you follow-up questions.
Task 3: Create a “what not to do” checklist (1 pomodoro)
List common thrash behaviors (rerun without change, change multiple variables, chase the final error) and the replacement habit for each.
Deliverable: a short anti-thrash checklist you’ll review before rerunning deployments.
Verification cue: you can state the replacement habit for each thrash item.
Task 4: Spaced review + teach-back (1 pomodoro)
Add 8 flashcards on evidence items and phase identification.
Deliverable: flashcards + a 60-second teach-back on “evidence first, then change.”
Verification cue: you can list the escalation kit fields from memory.
Day 5 — Post-Deploy Verification: Completeness, Placement, and “Success but Wrong”
Study Content
Deploy an Azure Local Instance Using Azure Portal — Validate deployment success and troubleshoot common issues using portal feedback
Focus: post-deploy inconsistency (resources created but misplaced, missing nodes, partial success)
Build a short “success verification” checklist
Tasks
Task 1: Build a 2-minute post-deploy verification checklist (1 pomodoro)
Write a checklist that verifies placement (subscription/RG/region) and completeness (expected resources present, expected nodes included).
Deliverable: a post-deploy verification checklist that can be run quickly after any “success.”
Verification cue: you can explain why “success” must still be validated for placement and completeness.
Task 2: Create a “missing nodes” first-response plan (1 pomodoro)
Draft a plan for when the portal deployment sees fewer nodes than expected (verify Arc placement, verify scope banner, verify onboarding evidence).
Deliverable: a 6–10 step plan that starts with Arc placement and scope, not with reimaging.
Verification cue: you can justify why node count mismatch is often an onboarding placement issue.
Task 3: Paper drill: “Success in wrong RG” (1 pomodoro)
Simulate a deployment that completed but resources are in the wrong RG and write your corrective steps.
Deliverable: a written corrective plan with the first three verification steps and the safest remediation choice.
Verification cue: your plan prevents accidental changes in the wrong environment.
Task 4: Spaced review + teach-back (1 pomodoro)
Create 10 flashcards pairing a post-deploy symptom with the quickest placement/completeness check.
Deliverable: flashcards + a 5-sentence teach-back on post-deploy validation.
Verification cue: you answer at least 7/10 correctly without notes.
Day 6 — Portal Deployment Readiness Check: Connecting Arc + Prereqs + Governance
Study Content
Register Azure Local Machines with Azure Arc — Execute the Azure Arc registration script and verify machine registration in the Azure portal
Identify Cluster Deployment Prerequisite Tasks — Explain how to assess environment readiness using the Environment Checker tool
Tie readiness artifacts (scope banner, evidence packs, Inventory.xml loop) into portal deployment success
Tasks
Task 1: Create a “Portal Deployment Readiness Gate” (1 pomodoro)
Write a readiness gate that must be true before launching portal deployment: Arc placement verified, connectivity primitives validated, readiness checks acceptable.
Deliverable: a one-page readiness gate checklist with explicit evidence references (which artifact proves each item).
Verification cue: you can point to the exact evidence artifact for each gate item.
Task 2: Build a “pre-deploy evidence bundle” folder plan (1 pomodoro)
Define a folder plan that bundles scope banner, Arc evidence packs, and readiness evidence so it’s easy to attach to tickets or change records.
Deliverable: a folder/index plan with file names and what each file proves.
Verification cue: you can assemble the bundle in under 5 minutes from your existing artifacts.
Task 3: Paper drill: validation blocks due to governance (1 pomodoro)
Simulate a portal validation block (allowed locations or required tags) and write the minimal compliant change to proceed.
Deliverable: a short remediation note that includes “what changed,” “why it’s compliant,” and “how you verify.”
Verification cue: you do not propose node changes when the portal blocks you at validation.
Task 4: Spaced review + teach-back (1 pomodoro)
Add 8 integration flashcards that connect Arc placement, readiness evidence, and portal deployment success.
Deliverable: flashcards + a 60-second teach-back on the “readiness gate” idea.
Verification cue: you can explain the gate sequence in order without notes.
Day 7 — Week 3 Integration Drill: One Full Portal Run + Two Failure Cases
Study Content
Execute a full “paper portal deployment” using your run sheet and readiness gate
Drill two failures: one validation deny, one execution failure with a clear first failing step
Produce a single-page “Portal Deployment Playbook” for final review
Tasks
Task 1: Paper-run a full portal deployment (1 pomodoro)
Using your run sheet, write out the inputs you would choose and the checks you would perform at each stage.
Deliverable: a completed run sheet + a short narrative of “what I checked and why.”
Verification cue: your narrative includes scope/placement confirmation before and after the run.
Task 2: Drill a validation deny scenario (1 pomodoro)
Simulate a deny due to location/tags and document phase, evidence, and the compliant input fix.
Deliverable: a triage note with phase classification and a single-change rerun plan.
Verification cue: you fix inputs/governance evidence before discussing node readiness.
Task 3: Drill an execution failure scenario (1 pomodoro)
Simulate an execution failure and identify the first failing step; route it to a cause bucket and define the first evidence to collect.
Deliverable: an escalation kit filled out for the scenario + your first two remediation actions.
Verification cue: you start with the first failing step, not the final error summary.
Task 4: Spaced review + cumulative recap (1 pomodoro)
Review all Week 3 flashcards and write a 5-minute recap of your portal triage method (run sheet → phase → bucket → evidence → change → rerun).
Deliverable: updated flashcards + the recap note.
Verification cue: you can summarize the method in 6 sentences without referencing notes.
Week 4 — ARM Automation, End-to-End Drills, Final Review
Week 4 Theme
This week makes you “deployment-scale ready”: you’ll set up and validate ARM template prerequisites (deployment identity, RBAC scope, secret lifecycle), practice parameterization for multi-site repeatability, learn to troubleshoot by finding the first failing deployment operation, and then run end-to-end drills that combine prerequisites → OS baseline → Arc onboarding → Portal/ARM deployment → evidence-based triage—finishing with a final, exam-style review loop driven by your mistake log.
Day 1 — Deployment Identity: Service Principal, Secrets, RBAC Scope
Study Content
Deploy an Azure Local Instance Using Microsoft ARM Templates — Prepare prerequisite Azure resources including service principals and secrets
Register Azure Local Machines with Azure Arc — Identify and resolve Azure policy or permission issues that may block registration
Focus: least-privilege RBAC at the correct scope + secret rotation planning
Tasks
Task 1: Build a deployment-identity “spec sheet” (1 pomodoro)
Summarize the required identity elements: tenant context, subscription scope, target resource group, and how the identity authenticates (secret/cert).
Deliverable: a 1-page spec sheet that you can attach to a change record.
Verification cue: you can point to the exact scope where RBAC must be applied (and explain why the wrong scope fails).
Task 2: Create an RBAC scope checklist (1 pomodoro)
Write a checklist that forces you to confirm (a) where the deployment will run, and (b) where the role assignment is actually granted.
Deliverable: a checklist with “Target scope” vs “Assignment scope” fields and a pass/fail line.
Verification cue: you can diagnose the classic trap “role exists on RG-A but deployment targets RG-B.”
Task 3: Write a secret/cert lifecycle plan (1 pomodoro)
Draft a lifecycle plan: track expiration, rotate before expiry, and validate a dry-run deployment after rotation.
Deliverable: a short lifecycle SOP with a rotation calendar field and a post-rotation validation step.
Verification cue: you can explain how an expired secret produces “used to work last month” auth failures.
Task 4: Spaced review + teach-back (1 pomodoro)
Create 8 flashcards pairing an auth-style symptom (unauthorized/forbidden) with the first 2 evidence checks (context + RBAC scope).
Deliverable: flashcards + a 60-second teach-back on “identity first, template second.”
Verification cue: you answer at least 6/8 correctly without notes.
Day 2 — Parameterization for Scale: Template Stable, Parameters Vary
Study Content
Deploy an Azure Local Instance Using Microsoft ARM Templates — Customize and execute ARM templates for scalable Azure Local deployment
Deploy an Azure Local Instance Using Azure Portal — Input required configuration parameters such as cluster name, resource group, and region
Focus: per-site parameter files + naming/region consistency + idempotent reruns
Tasks
Task 1: Design a parameter-file naming standard (1 pomodoro)
Define a naming convention for parameter files that encodes site and environment (e.g., SiteA-Prod, SiteB-Test).
Deliverable: a standard with at least 5 rules and 4 example file names.
Verification cue: you can tell which environment a parameter file targets from the name alone.
Task 2: Build a “parameter sanity check” checklist (1 pomodoro)
Create a checklist that validates critical parameters before execution (cluster name, RG, region/location, any governance-required tags).
Deliverable: a pre-run checklist with a “stop condition” if a critical field is missing or noncompliant.
Verification cue: you can explain how this prevents fast validation failures and repeated rerun thrash.
Task 3: Write an idempotent rerun rule (1 pomodoro)
Define a rerun rule set: one hypothesis per rerun, document the single change, rerun to converge, and re-verify results.
Deliverable: a 7-step rerun rule set for template deployments.
Verification cue: you can explain why changing multiple parameters at once destroys comparability.
Task 4: Spaced review + teach-back (1 pomodoro)
Add 10 flashcards linking “parameter mistake” to “likely failure pattern” (validation fail, name collision, wrong region).
Deliverable: flashcards + a 5-sentence teach-back on “template stable, parameters vary.”
Verification cue: you answer at least 7/10 correctly in under 4 minutes.
Day 3 — Troubleshooting Template Errors: First Failing Operation Wins
Study Content
Deploy an Azure Local Instance Using Microsoft ARM Templates — Validate ARM-based deployment results and resolve template errors
Deploy an Azure Local Instance Using Azure Portal — Validate deployment success and troubleshoot common issues using portal feedback
Focus: first failing step/operation + cause buckets (RBAC/auth, Policy, parameters, prerequisites)
Tasks
Task 1: Create a “first failing operation” method card (1 pomodoro)
Write a 6-step method: find deployment → open operations → identify first failure → record resource/type → classify bucket → choose first evidence.
Deliverable: a one-page method card you can follow under time pressure.
Verification cue: you can explain why the first failing operation matters more than the final summary error.
Task 2: Build an error-bucket routing table (1 pomodoro)
Create a table mapping each bucket to its first evidence items (RBAC scope proof, policy deny details, parameter correctness, prerequisite completeness).
Deliverable: a routing table you can use for both portal and ARM troubleshooting.
Verification cue: you can route “deny” vs “forbidden” vs “timeout” without mixing layers.
Task 3: Assemble a “template failure kit” template (1 pomodoro)
Create a template that captures deployment name/time, target subscription/RG, first failing operation, full error text, template/parameter version, identity used.
Deliverable: a fill-in template that becomes your escalation-ready note.
Verification cue: you can fill it in within 3 minutes from a hypothetical scenario.
Task 4: Spaced review + teach-back (1 pomodoro)
Create 8 flashcards that each start with an error snippet style (“unauthorized”, “deny”, “missing parameter”) and end with the bucket + first evidence.
Deliverable: flashcards + a 60-second teach-back on the bucket routing.
Verification cue: you answer at least 6/8 correctly without notes.
Day 4 — End-to-End Drill 1: “Clean Run” with Evidence Artifacts
Study Content
Identify Cluster Deployment Prerequisite Tasks — Explain how to assess environment readiness using the Environment Checker tool
Perform Operating System Deployment Tasks — Verify system contents post-imaging using PowerShell commands
Register Azure Local Machines with Azure Arc — Execute the Azure Arc registration script and verify machine registration in the Azure portal
Tasks
Task 1: Run a paper “foundation gate” (1 pomodoro)
Using your Week 1 artifacts, walk through readiness: baseline contract, connectivity categories, Inventory.xml loop, OS acceptance gate.
Deliverable: a checklist marked pass/fail with a note on what evidence proves each pass.
Verification cue: you can point to the exact artifact for each gate item (not just “I think it’s fine”).
Task 2: Validate the node evidence pack structure (1 pomodoro)
Review your five-bucket evidence pack and ensure you could compare Node04 vs Node01 by category quickly.
Deliverable: an updated evidence-pack index (files + what each proves).
Verification cue: you can state which evidence bucket you’d check first for an Arc timeout.
Task 3: Simulate Arc placement verification (1 pomodoro)
Perform a “portal placement check” drill: subscription/RG/location correctness + basic connectivity signal expectation.
Deliverable: a 2-minute portal verification checklist and a sample filled-out record for one node.
Verification cue: you can explain why placement checks come before RBAC/policy changes.
Task 4: Spaced review + teach-back (1 pomodoro)
Add 8 integration flashcards that connect prerequisites → OS evidence → Arc placement → deployment readiness.
Deliverable: flashcards + a 5-sentence teach-back of the end-to-end sequence.
Verification cue: you can explain the full sequence in order without notes.
Day 5 — End-to-End Drill 2: Mixed Failure (RBAC vs Policy vs Connectivity)
Study Content
Register Azure Local Machines with Azure Arc — Identify and resolve Azure policy or permission issues that may block registration
Deploy an Azure Local Instance Using Azure Portal — Validate deployment success and troubleshoot common issues using portal feedback
Deploy an Azure Local Instance Using Microsoft ARM Templates — Validate ARM-based deployment results and resolve template errors
Tasks
Task 1: Drill A — Forbidden during onboarding (1 pomodoro)
Write a triage note for a “Forbidden” failure: confirm scope banner, confirm assignment scope, confirm least-privilege remediation.
Deliverable: a 10-line triage note that ends with a rerun decision and a verification cue.
Verification cue: your first two checks are tenant/subscription context and RBAC scope alignment.
Task 2: Drill B — Deny due to location/tags (1 pomodoro)
Write a triage note for a deny policy: capture policy evidence, choose compliant inputs first, define the smallest change to proceed.
Deliverable: a remediation note that includes “before/after” evidence capture fields.
Verification cue: you explicitly state why permissions changes won’t bypass a deny policy.
Task 3: Drill C — Timeout / cannot reach endpoint (1 pomodoro)
Write a triage note for a timeout: DNS → time → outbound HTTPS → proxy/TLS inspection compatibility.
Deliverable: a 4-layer funnel with the first evidence item per layer.
Verification cue: you do not propose RBAC/policy changes until connectivity primitives are proven.
Task 4: Spaced review + teach-back (1 pomodoro)
Create 10 flashcards: 3 RBAC, 3 Policy, 3 Connectivity, 1 “mixed symptoms” integration card.
Deliverable: flashcards + a 60-second teach-back on avoiding layer thrash.
Verification cue: you can route each symptom to the correct bucket immediately.
Day 6 — Final Review: High-Yield Checklists + Mistake Log Loop
Study Content
Consolidate: baseline contract, connectivity ask, Environment Checker loop, image lifecycle, evidence packs, Arc onboarding playbook, portal run sheet, ARM troubleshooting method
Focus: fast recall + correct first action under time pressure
Convert weak spots into targeted drills
Tasks
Task 1: Create a one-page “exam day checklist” (1 pomodoro)
Compress your top workflows into a single page: what to verify first for each major symptom class.
Deliverable: a one-page exam day checklist with 6–10 lines and clear “first evidence” cues.
Verification cue: you can use it to answer “what do you do first?” questions without hesitation.
Task 2: Build a mistake-log review loop (1 pomodoro)
Review your mistake log and group mistakes into buckets (scope drift, governance, connectivity, drift/evidence).
Deliverable: a bucketed mistake log with one corrective action per bucket.
Verification cue: each bucket has a measurable action (rewrite checklist, redo drill, add flashcards).
Task 3: Do two timed mini-simulations (1 pomodoro)
Pick two scenarios (one portal, one ARM) and answer in 6 minutes each: phase/bucket/first evidence/first action.
Deliverable: two written answers with a timestamp and a “what I would verify next” line.
Verification cue: you can classify phase and bucket correctly within the first minute.
Task 4: Spaced review + teach-back (1 pomodoro)
Review all Week 4 flashcards and add 6 “trap pattern” cards (deny vs forbidden vs timeout, wrong RG, wrong region).
Deliverable: updated flashcards + a 5-sentence teach-back of your overall troubleshooting approach.
Verification cue: you can describe your approach as “phase → bucket → evidence → smallest change → rerun.”
Day 7 — Final Mock: Full Implementation Story + Self-Grading
Study Content
Run one full mock story: prerequisites → OS deployment → Arc registration → portal deployment → ARM deployment
Use only your artifacts (run sheets, evidence packs, decision trees)
Self-grade with a rubric focused on first action correctness
Tasks
Task 1: Write the full mock story (1 pomodoro)
Create a 1–2 page narrative that describes each step, what you validated, and what evidence you captured.
Deliverable: the narrative + a list of artifacts referenced at each step.
Verification cue: each step has a “proof” line (what evidence confirms it’s correct).
Task 2: Inject one failure and triage it (1 pomodoro)
Pick one failure (validation deny, RBAC forbidden, timeout, or template parameter mismatch) and write your triage path.
Deliverable: a triage worksheet using phase → bucket → evidence → action → rerun.
Verification cue: you identify the correct first evidence item and avoid changing multiple variables.
Task 3: Self-grade with a first-action rubric (1 pomodoro)
Grade yourself using 5 criteria: scope correctness, phase recognition, bucket routing, evidence quality, minimal-change rerun strategy.
Deliverable: a rubric scorecard with one improvement action per criterion that scored low.
Verification cue: your improvement actions are specific and scheduled (e.g., “redo Drill B tomorrow”).
Task 4: Spaced review + final recap (1 pomodoro)
Do a final review of the full flashcard set and write a 6-sentence final recap of the exam workflow.
Deliverable: final flashcard stats (correct/incorrect counts) + the recap note.
Verification cue: you can explain the end-to-end implementation sequence in under 90 seconds.