A museum analytics service consumes Meraki Scanning POSTs. Which fields should the constructed consumer treat as the core location retrieve?
Select an answer to reveal the explanation.
Short Explanation
You are reading who was seen and where—the observation’s MAC (and maybe IP) plus coordinates when enough APs heard the client. Missing lat/lng is often a coverage fact, not a parse bug.
Full Explanation
A museum analytics service consuming Meraki Scanning POSTs should treat the observation array’s client identity and location fields as the core retrieve. That typically means MAC address (and optionally IP when present) plus location attributes such as lat/lng or floorplan x/y when the cloud could compute a position from sufficient AP/BLE sightings. Those fields answer who was seen and where for wayfinding or analytics without requiring unrelated firewall or RF-planning payloads.
Using only the SSID enabled boolean from a parallel Dashboard PUT fails: that boolean is WLAN config state, not a location observation. Expecting FDM networkobject subType values inside Meraki JSON fails by mixing Secure Firewall object models into Scanning posts. Requiring full floor-plan RF heatmaps and AP channel plans on every observation fails practicality—per-event posts carry observations, not complete RF engineering dumps.
Exam caveat: missing lat/lng often means insufficient AP geometry or computation, not necessarily a broken JSON parser; design consumers to tolerate partial location.
Operational check: capture a sample POST, assert an observations list with MAC (and location when present), and unit-test your parser against posts that omit coordinates as well as posts that include them.