Pat's arrangement supports a simple multiple choice survey style arrangement that will not meet your needs directly, however it is the basis for a more sophisticated design.
If you notice, each question can have a different list of responses and the answer allows for both a selection and a text answer.
I can't post my medical example which is a questionnaire used to help the visiting nurses decide on what types of home health aid a new client will need. In the medical example, there are three variations of the questionnaire and of course because the schema is properly normalized, an "infinite" number are possible. The medical version also has two levels of grouping to allow for logical breaks and coherent reporting.
@bonzitre I know that you really don't want to hear this. You've done a ton of work but your new schema is way off the mark and I suggest that you go back to square one. Throw it all out. Every bit of it. Chalk it up to learning how to properly normalize a schema. Your design will be extremely difficult to work with and will require constant maintenance as the survey changes over time. You are making a maintenance nightmare for yourself.
Do yourself a favor and try to create a survey with your questions but only go with a dozen or so so you see how it comes together. You will probably want a slightly more sophisticated schema than my teaching example but once you understand the teaching example, you will better understand how to proceed with this project.
Each column in tables 2-11 should be a row in a single table.
Regarding your naming of columns. Do not use all lower case or all upper case for that matter. Use CamelCase so you can distinguish individual words. Of course I'm looking at column names that shouldn't exist but I see that you are also using all lower case in the other tables.
Looks like you have a slew of tables with value lists. I'm attaching a mini-app I use in all my applications. It provides a simple way to manage all your simple lookup lists in ONE table and one set of forms. When I use this in my apps, I can also allow an admin in the user department to manage the lists so they can add new items or change the names of existing ones. Deletes are not allowed. If you don't want to use an item going forward, you mark it as inactive. That doesn't break old surveys but with a couple of lines of code, prevents the user from using the inactive value for new surveys.
When you have several lookup tables in an application, it becomes a pain to create separate tables and maintenance forms to manage the contents. This sample is an application that I first developed over 40 years ago, long before Access was a twinkle in Bill's eye. It was constructed using...
www.access-programmers.co.uk
I don't use the table-maintenance mini-app in the survey because the survey sample used an embedded method and I didn't want to rebuild the sample to incorporate the table-maintenance mini-app but once you understand the concept, you can decide which method would be best. If the "lists" are reused in multiple places then it will be less work for you to use the table-maintenance concept. If all the combos are unique then it doesn't matter so you can use either.