Sure, this make perfect sense to me. Using your automobile example, I'd use three tables. One for manufacturer, one for options, one for "allowed options". Manufacturer would have a primary key defined (some column/attribute to uniquely identify each manufacturer), and so would options). The primary key for the "allowed options" table would be the combination of the primary key values from the manufacturer and the option (with foreign key constraints so that only values from the other tables can be used within the "allowed options" table).
Using your example, you need to think a bit about how you want to track model years and which option values are allowed. Sometimes these change over time.
Thanks PatP for your reply!
following your example: what about possible values the option 'Engine' can take for 'Toyota'? Would I need two more tables for that? (i.e. one for a list of all Engines and another one to relate the allowed engines to the option 'Engine')
This is what is not very clear to me.
It depends on how you plan to use the breakdowns. So far, you've only discussed lists of manufacturers and options, so options could include "4 cylinder Toyota", "6 cylinder Toyota", "4 cylinder Ford", and "4 Cylinder widget". If you need more power to manipulate the option data, so that you need to track more details about those options, then you have a more complex problem that might make those sub-tables necessary.