Yes, you are correct that saving a list (with data) as a template makes a one time copy of the original list.
If you need the copy list to reflect updates to the source list, I don't think there's any way you are going to get that done without some kind of "code" solution, although my suggestion involves Flow, so I don't know how much you consider Flow to be "code".
I've had to do a similar thing in the past (keep a related copy of an item in a different list updated according to the changes on a source item), and although I was working in SP 2013 using 2013 workflows, I'm sure the same idea could be implemented in SP Online using Flow.
Here's the general idea:
- Add a number (integer) column to the source list called "Copy Item ID". Perhaps have it default to zero.
- Create a workflow/Flow that runs on both item added and item updated
- When the workflow runs, check the value of the "Copy Item ID" field. If it's zero (or blank), you know you haven't created the copy in the other list yet, so just go ahead and create the copy in the other list, but make sure to get that copied item's list ID, and save that in the source item's "Copy Item ID" field.
- If the value of "Copy Item ID" is not zero (or not blank), you know you have created the copy already, so use the value of "Copy Item ID" to get the copied list item in the copy list, and update it. You won't know which field or fields were updated, so you'll have to update all the fields in the copied item to the values of the source item, essentially syncing it with the source item.
If you are expecting users to make changes to the items in the copy list, and you want to somehow preserve those changes while you make your updates from the source list, you are going to have to come up with a bunch of additional logic.
If you want to only update the fields that were changed in the source item, that can be done, but it involves creating hidden fields on the source item that correspond with every visible field to store the previous value of that field, so when the workflow runs you can check the current field value against the previous field value, and thus know which fields actually changed. Do-able, but a lot of work.
But really, the simpler way to prevent users from making changes to a list is to break permission inheritance on the list, make it read-only to most users, and have only a specific group have contribute permissions.