Exercise 2: A ServiceMonitor for inventory-api — Possible Solution
====================================================================

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: inventory-api
spec:
  selector:
    matchLabels:
      app: inventory-api
  endpoints:
    - port: metrics
      interval: 15s

Explanation:

This follows the chapter's own checkout-api example exactly, with the
service-specific values swapped in: metadata.name identifies this
ServiceMonitor object itself, spec.selector.matchLabels tells the
Prometheus Operator to find any Kubernetes Service carrying the label
app: inventory-api, and spec.endpoints specifies which named port on
that matched Service to scrape ("metrics") and how often (every 15
seconds, per the exercise's own requirement).

-- What happens automatically once this is applied --
--
-- The Prometheus Operator, which is continuously watching for
ServiceMonitor objects across the cluster, detects this new one and
automatically reconfigures the underlying Prometheus instance it
manages to add inventory-api as a new scrape target -- with no manual
edit to any prometheus.yml file, and no manual reload or restart of
Prometheus itself required. As long as a Service already exists in
the cluster carrying the app: inventory-api label and exposing a port
named "metrics", Prometheus begins scraping it within moments of this
ServiceMonitor being applied, live, exactly the declarative behavior
the chapter describes as ServiceMonitors' own real advantage over a
hand-maintained static target list.

WHY THIS WORKS AS AN ANSWER
------------------------------
This writes a correctly structured ServiceMonitor matching the
chapter's own field names and exercise-specified values, then
explains the Operator's own reconciliation behavior concretely rather
than just stating "Prometheus starts scraping it."