Tests, an independent extension and a handoff

Write expected results before copying the rule

A useful test compares the program with an independently stated result. Repeating the implementation inside the test can reproduce the same defect twice. The following check executes the saved script using the six-row fixture and checks literal expected outcomes.

$expected = @{
    APP01='NoFinding'; APP02='Review'; APP03='Review'
    APP04='NoFinding'; APP05='Invalid'; APP06='Invalid'
}
$output = Join-Path ([System.IO.Path]::GetTempPath()) ('ck-' + [guid]::NewGuid() + '.csv')
try {
    & pwsh -NoProfile -File ./Report-Services.ps1 -InputPath ./services.csv -OutputPath $output
    if ($LASTEXITCODE -ne 0) { throw 'Baseline command failed' }
    $actual = @(Import-Csv -LiteralPath $output)
    if ($actual.Count -ne 6) { throw 'Expected exactly six report rows' }
    if (@($actual | Group-Object Host | Where-Object Count -ne 1).Count -ne 0) {
        throw 'Baseline must contain each expected host exactly once'
    }
    foreach ($hostName in $expected.Keys) {
        if ($hostName -notin $actual.Host) { throw "Missing expected host $hostName" }
    }
    foreach ($row in $actual) {
        if (-not $expected.ContainsKey($row.Host) -or $row.Assessment -ne $expected[$row.Host]) {
            throw "Unexpected assessment for $($row.Host)"
        }
    }
    'Six baseline assessments passed'
} finally {
    if (Test-Path -LiteralPath $output) { Remove-Item -LiteralPath $output }
}

The baseline check also verifies that each expected host appears once. Merely checking six row assessments would miss a duplicate host replacing a missing host when both assessments look valid. The cleanup deletes only the unique temporary output created for this check. It does not use a wildcard over a shared directory. Even a test script should keep a narrow deletion boundary.

Change the classifier's -lt 2 to -le 2 in a separate copy. The test must fail for APP04. Restore the original and run it again. A deliberately introduced defect demonstrates that the test is sensitive to the rule it claims to verify.

This baseline check does not verify every schema error or file failure. Keep a second test table listing the negative cases from Chapter 3, their expected exit code, whether output should exist, and the source-file hash before and after. The combination is stronger than a single successful run.

Project A — Make the threshold configurable

Add a parameter named MinimumUptimeHours with a documented accepted range. Pass it into the classifier rather than reading a global variable. Keep the default at 2 so the baseline results remain unchanged. Test thresholds 0, 2 and 12, and test a negative value. Decide whether 0 means no running service can fail this uptime rule; explain that behavior in the README.

At threshold 12, APP01 with uptime 12 must still have NoFinding. APP03 and APP04 must need review. Stopped services remain reviewable independently of uptime. Invalid rows remain invalid. These expected results expose both boundary mistakes and accidental coupling between the status and uptime rules.

Project B — Detect duplicate observation identities

Define a key of host and service name after your documented normalization. A duplicate key means two observations describe the same service identity in this file. Do not choose the “latest” row when the file has no timestamp. Preserve both rows in a rejection report or fail the batch; state which policy you chose.

Add two fixtures: the same key with conflicting states, and a host with two different service names. The first must trigger your duplicate policy. The second must not be incorrectly collapsed into one service. A host count and a service count are different quantities.

Project C — Plan a live read-only adapter

Keep the classifier separate and design a collector that supplies the same fields. Research which properties your target platform can actually provide. Get-Service is not a universal source of an accurate uptime duration on every system. If uptime cannot be established, mark it unavailable rather than inventing a value of zero.

Document the collection identity, platform, collection time, failed targets and expected population. A collector that reached two of ten machines should not publish a “healthy fleet” conclusion based on the two successful responses. This extension is a design task until you test it on an authorized environment; the course's offline fixture does not validate remote collection.

Handoff acceptance criteria

Submit the source fixture, script, baseline report, a separate failure-results table and a short README. The README must state the row grain, accepted states, numeric rule, threshold boundary, output overwrite policy and validation limitations. A reviewer should be able to reproduce the baseline without changing machine configuration.

Explain why a stopped service observation requests review rather than authorizing an automatic restart. The service may be intentionally disabled or under maintenance; restarting it changes the environment and requires additional context and authority. Explain why an invalid observation cannot be counted as healthy. Explain why formatting before CSV export breaks a data pipeline even when the console looks attractive.

You have completed the course when you can change a requirement, predict the changed results, expose a deliberate defect and defend your reporting boundary. Completion of the website's lesson check records study progress; it does not certify that you can administer an unfamiliar production environment.

Reference: https://learn.microsoft.com/en-us/powershell/scripting/learn/ps101/00-introduction

Transfer project — changed conditions

Add E with FreeGB greater than SizeGB and F with a negative value. Extend validation with an explicit policy for inconsistent data. Write tests for 9.99%, exactly 10%, 10.01%, zero and missing input. Export the structured result, import it again and check field names and values. Explain which steps are presentation-only and why a clean-looking table does not prove the underlying calculation.

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

• My input/evidence and assumptions:
• Expected result with calculations or trace:
• My implementation/decision and justification:
• Changed-condition result:
• Observed execution, or explicitly labeled manual trace:
• Failure and recovery evidence:
• Unverified limitation and next action:
• Self-score with evidence for each dimension:

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. What generally flows through this pipeline?

1. Objects
2. Only screenshots
3. Only shell text

Answer and explanation

Objects — PowerShell passes structured objects between these commands.

2. Where should Format-Table normally go?

1. Before every filter
2. At the display end
3. Inside CSV records

Answer and explanation

At the display end — Formatting objects are intended for presentation.

3. What does -ExpandProperty Name return?

1. All object methods
2. A new administrator role
3. The Name values

Answer and explanation

The Name values — Expansion returns property values rather than selected wrapper objects.

4. Your console table looks correct, but the CSV has formatting-property columns. Which change repairs the data pipeline?

1. Remove Format-Table before export and select the intended object properties.
2. Increase terminal width before running Export-Csv.
3. Parse the rendered spaces to reconstruct rows.

Answer and explanation

Remove Format-Table before export and select the intended object properties. — Formatting emits display instructions rather than the original service objects. Select-Object preserves a data interface; terminal width changes presentation and does not restore that interface.

5. A running service has uptime exactly 2 hours under a below-2-hour review rule. What is expected?

1. Review because the duration is low.
2. NoFinding for this rule, while broader health remains unproven.
3. Invalid because uptime must be greater than 2.

Answer and explanation

NoFinding for this rule, while broader health remains unproven. — The strict condition is -lt 2. NoFinding is the classifier result for the supplied fields; it does not prove service health, availability or correct configuration.

6. A real service collector cannot establish uptime for one target. Which export is defensible?

1. Write zero so the report always has an integer.
2. Omit the machine and describe all collected machines as healthy.
3. Keep the value unavailable and carry the collection limitation.

Answer and explanation

Keep the value unavailable and carry the collection limitation. — Unavailable evidence is different from measured zero. A live adapter needs collection-status and coverage evidence; the synthetic fixture does not validate every platform property.

7. What is B’s state under the stated rule?

1. OK at exactly 10%.
2. Alert because the threshold is inclusive.
3. Invalid because every round number is invalid.

Answer and explanation

OK at exactly 10%. — The rule is strictly below 10, not less than or equal to 10. Boundary tests protect this distinction.

8. How should C be represented?

1. Alert at a safely computed 0%.
2. Invalid because capacity is zero.
3. Healthy at 100% free.

Answer and explanation

Invalid because capacity is zero. — Division by zero has no valid percentage here. Reporting a health state would hide invalid source data.

9. Where should Format-Table occur?

1. Before Export-Csv to preserve raw objects.
2. Before numeric validation.
3. At presentation time, after the data pipeline used for export.

Answer and explanation

At presentation time, after the data pipeline used for export. — Formatting changes the pipeline into formatting instructions. Keep report objects intact for calculations and serialization.

Open the scored course assessment to use the existing practice-test engine. Earlier attempts remain part of your history.