Can grep check that my database volume is named db-data?

I would use a YAML parser such as yq rather than grep. Read each file, select the db service, then check its volumes. That keeps a cache volume like cache-data from being mistaken for a database volume.

Decide what the rule should do with bind mounts, anonymous volumes, long-form mounts, and a db service with no volumes. Compose supports more than the short source:target syntax, so a check written only for that example can miss valid configurations or flag things you did not mean to reject.

Grep can work as a rough check if every file follows a tightly controlled layout, but matching across lines is the tricky bit. A pattern that starts at db and searches forward for volumes can wander into the next service. It can also miss a bad second mount if the first one is db-data.

Indentation, quoted strings, comments, and long-form volume definitions make a general regex check pretty fragile. I would not rely on it as the enforcement step unless the input format is deliberately restricted.

If the containers are already running, inspect the database container and parse its mounts with jq. That checks what is actually mounted rather than what one YAML file says.

It answers a slightly different question, though. It cannot validate files before deployment, and the effective runtime volume name may include a Compose project prefix, so compare against the naming rule you actually intend to enforce.

A small validation script is another option if the rule is going to grow. Parse the YAML, examine the db service mounts, and report the filename and offending mount before exiting with a nonzero status. That makes the failure useful in an automated check without trying to squeeze all the logic into a regex.