Challenge 1: Pick the Right BSON Type — Possible Solution
====================================================================

(a) A customer's account balance in dollars
    -> Decimal128.
    This is exactly the "anything involving money" case this chapter
    warned about — using the default Double type risks tiny floating-
    point rounding errors that can accumulate into a genuinely wrong
    balance over many transactions. Decimal128 stores an exact
    decimal value instead, avoiding that class of bug entirely.

(b) An order's placement timestamp
    -> Date (the real BSON Date type, e.g. ISODate(...)) — NOT a
       string.
    This is exactly the date-as-string gotcha this chapter covered:
    storing "2026-07-06" as a plain string might look fine at a
    glance, but range queries against it compare lexicographically
    rather than chronologically, which breaks the moment formats or
    precision vary. A real Date value keeps range queries correct
    regardless of formatting.

(c) A product's list of tags
    -> Array (of strings).
    Tags are inherently a variable-length list of simple values
    belonging to one product — the same "Arrays and Nested
    Documents" pattern the chapter described, no different BSON type
    needed here since each individual tag is just a String.

WHY THIS WORKS AS AN ANSWER
------------------------------
Each answer maps directly onto one of the specific pitfalls or
patterns this chapter called out by name: Decimal128 for the
floating-point-and-money gotcha, a real Date type for the date-as-
string gotcha, and a plain Array for ordinary list-shaped data with
no special type consideration needed.