AI0-001 Implementing AI Solutions Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Disable model monitoring on the device to reduce CPU overhead and extend battery life.

  Why it's wrong here

  Disabling monitoring removes visibility into accuracy drift, hardware faults, and data quality issues, which undermines reliability in a production edge fleet. Monitoring can be made lightweight rather than removed. The scenario requires reliability, and without telemetry the team cannot detect or correct degradation when trucks return online, so this practice is counterproductive.

• ✗

  Increase the model's parameter count so it can learn more complex delay patterns from historical data.

  Why it's wrong here

  Larger models increase memory, compute, and latency demands, which is the opposite of what constrained edge hardware needs. The scenario prioritizes latency and reliability, not maximum model capacity. A larger model also makes on-device inference harder and may not fit the device at all, so it is not an appropriate implementation practice here.

• ✓

  Quantize the model to a smaller numeric precision so it fits the device's memory and compute budget.

  Why this is correct

  Quantization reduces model size and compute cost, which directly addresses the memory and latency constraints of edge hardware in trucks. It enables local inference without relying on a network round trip, supporting the intermittent-connectivity requirement. This is a standard optimization for constrained edge deployment and preserves acceptable accuracy when validated against the original model.

• ✓

  Implement local inference with store-and-forward caching so predictions continue offline and sync when connectivity returns.

  Why this is correct

  Local inference keeps the model running when the truck loses connectivity, and store-and-forward caching queues telemetry or results for later synchronization. Together they satisfy the reliability requirement for intermittent links. This pattern avoids failed predictions during outages and preserves data integrity once the device reconnects to the central system.

• ✗

  Route every prediction request to the cloud so the model always uses the newest weights.

  Why it's wrong here

  Cloud routing depends on continuous connectivity, which the scenario explicitly says is intermittent. Requests would fail or time out during outages, violating the reliability requirement. It also adds network latency that conflicts with the latency goal. Keeping the model current is useful, but it cannot be the primary strategy for a disconnected edge environment.