Investigating a Source-of-Truth Compliance Gap

Scenario

The problem

"Why Model Your Network as Data?" argued that a source of truth only earns its name if reality actually matches it. This lab is that argument made concrete: NetBox declares four devices should exist, with specific platforms. A separate scan of the actual fleet found three of them -- and one of those three doesn't match what NetBox says it should be. Neither the NetBox list alone nor the scan alone tells you what's wrong; only comparing them does.

Smaller than the Capstone, on purpose

This is a single investigation, not a pipeline. It stops at "here's the gap" -- it doesn't generate a remediation, commit anything to Git, or stage a rollout. The Capstone module builds that full chain; this lab is deliberately just the first link.

Starter data

starter.py

# Stands in for records already retrieved via pynetbox -- the platform
# field is what NetBox declares each device to be.
NETBOX_DEVICES = [
  {"name": "RTR1", "site": "hq", "platform": "cisco_ios"},
  {"name": "RTR2", "site": "hq", "platform": "cisco_ios"},
  {"name": "SW1", "site": "branch1", "platform": "arista_eos"},
  {"name": "SW2", "site": "branch1", "platform": "junos"},
]

# Stands in for what a live fleet scan actually found -- built
# independently of NETBOX_DEVICES.
OBSERVED_DEVICES = [
  {"name": "RTR1", "platform": "cisco_ios"},
  {"name": "SW1", "platform": "arista_eos"},
  {"name": "SW2", "platform": "cisco_ios"},
]

Fixed sample data written for this lab. RTR2 never appears in OBSERVED_DEVICES; SW2 appears with a different platform than NetBox declares -- both deliberate.

Task

Write find_missing_from_scan(netbox_devices, observed_devices) — device names NetBox lists that never appear in the observed list.

Write find_platform_drift(netbox_devices, observed_devices) — for every observed device that is in NetBox, check whether its observed platform matches NetBox's declared platform. Return a list of dicts naming the device, NetBox's platform, and the observed platform, for every mismatch.

Write compliance_gap_report(netbox_devices, observed_devices) combining both into {"missing_from_scan": [...], "platform_drift": [...]}.

Hints

Expected output

expected output

{'missing_from_scan': ['RTR2'], 'platform_drift': [{'device': 'SW2', 'netbox_platform': 'junos', 'observed_platform': 'cisco_ios'}]}

Real, verified output. Two genuinely different findings from the same run: one device NetBox expects but the scan never saw, and one device the scan saw but mislabeled relative to NetBox.

Validation checklist

find_missing_from_scan() returns exactly ['RTR2']
find_platform_drift() returns exactly one entry, for SW2
RTR1 and SW1 appear in neither result -- they match cleanly
compliance_gap_report() combines both into the exact two-key dict shown above

Self-check only -- nothing here is submitted or graded. Compare against your own output manually.

Solution

Try the task yourself first -- the full solution and explanation stay hidden until you click above.

Key takeaways

A source of truth is only as useful as the last time it was actually checked against reality -- this lab is that check, done directly.
"Missing entirely" and "present but wrong" are genuinely different findings that need separate detection logic, not one merged check.
Deliberately smaller than the Capstone: an investigation that stops at the finding, not a remediation pipeline.
Both device lists are fixed sample data -- no real NetBox server or device scan was involved.

Investigating a Source-of-Truth Compliance Gap

Objective

Prerequisites

Scenario

Starter data

Task

Expected output

Solution

Related lessons