Understand boot integrity, memory hierarchy, asset evidence and test the resulting controls with reproducible evidence.
45 min 120 XPSkills: Boot integrity, Memory hierarchy, Asset evidence
Brief
Northwind Freight needs defensible evidence for computer architecture, not a vocabulary quiz. Start with the system boundary and trace how a technical state changes the confidentiality, integrity or availability of the service. A passing document is not a passing running system.
You will examine boot integrity, memory hierarchy, asset evidence, then make short incident decisions and author a testable specification. Keep desired state, observed state and evidence separate: an approved requirement tells you what should happen, while a dated observation tells you what actually happened.
Never convert missing evidence into a passing control result.
Compute and memory
A CPU executes instructions while registers and caches keep frequently used operands close to the execution units. RAM holds working pages and normally loses their contents when power stops; persistent storage retains files. A 64-bit address space does not mean a machine contains that much RAM: installed capacity, address translation and operating-system limits constrain what processes can use.
When a workload exceeds physical memory, paging moves less-used pages to persistent storage. This is slower than RAM and can expose sensitive memory contents unless swap is protected. A full disk and exhausted RAM are different failure modes; collect memory pressure, page-fault rates and storage free space before buying more processor cores.
Capacity management supports availability. Retain dated inventory exports and performance samples; an auditor asks whether a capacity exception was measured, assigned an owner and resolved before it affected the service.
Compute and memory requires both a declared boundary and independently testable observations.
Firmware and the boot chain
After reset, firmware initializes hardware and selects a boot target. A bootloader loads the kernel, which initializes drivers and starts the initial user-space process. Each executable stage is a potential persistence point: reinstalling an application does not necessarily remove compromised firmware or an altered bootloader.
Secure boot verifies signatures against configured trust anchors before allowing a boot component to execute. Measured boot instead records cryptographic measurements for later attestation; recording a hash is not itself blocking execution. Trusted signing keys, revocation state and recovery procedures matter as much as an enabled toggle.
Platform-integrity controls need firmware versions, signature-policy state and failed verification events tied to asset identifiers. An auditor asks whether the sampled device actually enforced its trust policy during the period, rather than whether the model supports the feature.
Firmware and the boot chain requires both a declared boundary and independently testable observations.
Storage and the evidence boundary
Block devices expose numbered storage blocks; a filesystem organizes those blocks into files and metadata. A device marketed as one terabyte uses decimal units, while a tebibyte is 2^40 bytes. Usable filesystem capacity is smaller after formatting, reserved space and redundancy; capacity figures alone cannot establish backup coverage.
Separate inventory facts from assurance claims. Serial number, firmware revision and RAM size describe an asset; a signed boot event demonstrates one integrity decision. Neither proves that every application is patched or that a file can be recovered after accidental deletion. Keep the collection timestamp and collection scope with each observation.
Asset management controls require reconciliation between expected and observed devices. Preserve missing-device exceptions and their resolution; an auditor asks which assets never reported, not merely how many rows appeared in the latest export.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: Volatile is not persistent
Scenario sim+40 XP
Read the brief and answer both questions.
Incident brief
A technician calls the 16 GiB working-memory module permanent storage because an application can keep values there all day. The security lead instead wants to block unsigned boot code before the kernel starts.
Term bank, not all of these are right
RAMsecure bootdiskmeasured boot
1.1Which component loses its working contents on power loss? (one acronym)
1.2Which boot control blocks untrusted signed-chain execution? (two words)
Task 2: Observation is not enforcement
Scenario sim+40 XP
Read the brief and answer both questions.
Incident brief
An inventory records boot-stage hashes but permits every image to run. A manager calls this signature enforcement. The earliest low-level initialization code is also out of date.
Term bank, not all of these are right
measured bootfirmwaresecure bootapplication
2.1What boot approach records measurements without necessarily blocking execution? (two words)
2.2What component initializes hardware before the bootloader? (one word)
Task 3: Capacity is not coverage
Scenario sim+40 XP
Read the brief and answer both questions.
Incident brief
An assessor labels a raw numbered-block interface a filesystem and claims its capacity report proves recovery. A second export lists serial numbers and installed RAM, but no restore results.
The control owner calls the current summary complete because every field has a label. Several labels confuse a technical mechanism with assurance, and missing observations have been treated as passing.
Use the fixture as the authoritative requirement. Replace the empty fields with typed, testable values and identify the evidence needed to substantiate the claim. Do not copy the owner's optimistic summary.
Approved requirement and measured facts
Asset node-11 has 16 GiB RAM; approved policy requires boot signature enforcement, not measurement alone. Retain firmware version and signature-policy evidence.
The owner says all six statements are acceptable because they use technical vocabulary. Judge the actual claim, not the confidence of its author.
Accept accurate limited mechanism statements; reject false equivalence, excessive privilege, absent evidence, or conclusions beyond the observation.
Verdicts are accept or reject. Every rejection needs one reason code from: wrong-mechanism | excess-privilege | missing-evidence | unsupported-claim.
Claims submitted for assurance
IT1-1 A CPU executes instructions while registers and caches keep frequently used operands close to the execution units.
IT1-2 Treat "secure boot" as interchangeable with "RAM"; no mechanism check is needed.
IT1-3 Let every employee modify the protected service configuration without approval or review.
IT1-4 After reset, firmware initializes hardware and selects a boot target. This statement describes the mechanism only, not a complete audit conclusion.
IT1-5 Report a pass when the required observation is missing; no dated source is retained.
IT1-6 Claim that a documented boot integrity policy proves every in-scope asset complied throughout the year.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · IT Fundamentals
Operating Systems
Understand process isolation, service privilege, kernel boundaries and test the resulting controls with reproducible evidence.
