Campus access and cloud service responsibilities

Repair the campus access route and compare the cost and responsibilities of a self-hosted fog broker with managed AWS IoT Core.

Cloud Clara, your practice guide

Cloud Clara
Predict which checkpoint will change, then test the connection.

IoT Ideator

Design Studio

Simulation — built in · No account

Version tested: 36435f99ff6788e8acd2e3d1fb9309cd97b4f2e4. Date: 2026-09-06.

Open the prepared mission; follow the guide and live checkpoints.

Open this design in the Design Studio (new tab)

Steps

Screens captured against IoT Ideator 36435f99ff6788e8acd2e3d1fb9309cd97b4f2e4 on 2026-09-06; the tool may have moved on — the text steps are the contract.

  1. Step 1

    Do
    In the Working View canvas, select the Wi-Fi Module and inspect its access hop to AWS IoT Core.
    You will see
    Input: Selected Wi-Fi Module (ESP-01S) on the Site canvas. Observed: Physical placement shows AWS IoT Core 45.000 m away and an Over max length verdict. Expected: The mission gives this indoor Wi-Fi hop a 30 m teaching limit. Interpretation: The modelled hop is 15 m beyond that limit.
    Why it matters
    Evidence: The value and warning come from the live Ideator design model. Boundary: A drawn service path does not make its access hop usable. Ownership: Campus access remains the operator’s responsibility beside a managed core. Next check: Replace the refused hop and read the route checkpoint again.

  2. Step 2

    Do
    In the Site canvas, replace Wi-Fi with nearby NB-IoT, linking ESP32–NB-IoT by Data/UART and NB-IoT–AWS IoT Core by Data/NB-IoT.
    You will see
    Input: Removed the Wi-Fi-to-cloud edge, added NB-IoT, and connected ESP32 UART to NB-IoT and NB-IoT to AWS IoT Core. Observed: The new NB-IoT edge reports +43.28 dB link margin at 155.631 m in the catalogue model. Expected: The UART hop must stay within 15 m and the sensor-to-cloud route must return. Interpretation: Both connected-NB-IoT and managed-service-route checkpoints now pass.
    Why it matters
    Evidence: The new edges are labelled UART and NB-IoT on the Site canvas. Boundary: +43.28 dB is a design-model estimate, not a field radio measurement. Cause: Removing the refused Wi-Fi edge changed the access route used by the checkpoint. Next check: Inspect the fog alternative before comparing service ownership.

  3. Step 3

    Do
    In the Working View canvas, select the Fog Computing Node and inspect its connected alternative to AWS IoT Core.
    You will see
    Input: Selected Fog Computing Node in the Working View canvas after repairing access. Observed: The fog node remains linked to AWS IoT Core by an Ethernet edge. Expected: The self-hosted fog alternative must remain connected for comparison. Interpretation: The live alternative checkpoint passes beside the managed route.
    Why it matters
    Evidence: The canvas and scenario check establish a connected design alternative. Boundary: They do not establish field uptime, broker patching, or sensor accuracy. Ownership: A campus-operated fog host retains hosting and support work. Next check: Compare those duties with the managed-core responsibility rows.

  4. Step 4

    Do
    In the Day panel, read Operating cost / day and compare it with the mission’s $1 daily limit.
    You will see
    Input: Opened Day in the Life after the NB-IoT route repair. Observed: Operating cost / day reads $0.0015/day for broker and 103 B/delivered-reading transport. Expected: The mission’s daily operating-cost ceiling is $1. Interpretation: The displayed model number is below that ceiling; Day also shows 1,440 messages/day.
    Why it matters
    Evidence: Day calculates a bounded catalogue-backed operating figure. Scope: It omits labour, support, outage, migration, and other ownership costs. Reason: $0.0015/day cannot stand in for total cost of ownership. Next check: Open Service models for the 365-day configured comparison.

  5. Step 5

    Do
    In the Day panel, expand Service models and compare the 365-day totals and responsibility rows.
    You will see
    Input: Expanded Service models in the Day panel. Observed: Included 365-day totals are $5,787.07 self-hosted and $2,190.59 managed. Expected: Compare both totals with build, run, patch, and support owners. Interpretation: Managed rows are Shared; the model excludes migration from both totals.
    Why it matters
    Evidence: Self-hosted shows $380.00 measured plus $5,407.07 configured. Evidence: Managed shows $30.53 measured plus $2,160.06 configured. Boundary: “Measured” means read from the catalogue-backed Day result, not field metering. Decision: The purchased core shifts duties while campus still owns devices and access.

  6. Step 6

    Do
    In the Scenarios panel, enter the managed total, build/run/patch/support owners, retained fog duty, shifted core duty, and shared access failure.
    You will see
    Input: Entered the managed total and ownership explanation in the two Scenarios answer boxes. Observed: The saved answer quotes $2,190.59 = $30.53 measured + $2,160.06 configured. Expected: Connected access, managed route, cost split, and fog-ownership answers must pass. Interpretation: All four mission checkpoints pass and Reflect is available.
    Why it matters
    Evidence: The app marks both written answers Saved with enough concrete design evidence. Retained duty: Campus keeps devices, access, and fog-host operation if it chooses fog. Shifted duty: The provider runs and patches the managed core; access failure remains shared. Boundary: These are design-model assignments, not service-level or field measurements.

Chapter checks

These questions refer to the chapter’s examples. Use the return links to review their answers.

  1. A team wants to deploy an application they wrote without managing the operating system or server patching, but they still want to control the application's own configuration. Which service model definition matches this?

    Return to the chapter’s knowledge check

  2. In the responsibility bracket, which layers move from the user's column to the provider's column when going from Traditional to IaaS, and which layers stay with the user?

    Return to the chapter’s knowledge check

Return to Service Models: IaaS, PaaS, and SaaS · Browse Tutorials