The database should be used for storing thresholds and configurations that will be used by decision making logic in the code e.g. "User income is greater than X, suggest our Premium product" X will be in the DB, but the code that checks if User.Income > X should be in your C#/Java/other type strong language. For that you don't need anything other than tables like
Create Table IntSettings(
name varchar(100) not null,
value int not null
This "type strong" table declaration avoids misunderstandings like a fellow programmer trying to insert "$1000000" for a price setting because they feel they need to give the currency for whatever reason. This misunderstanding could cause some unexpected part of the code to explode when parsing the setting.
Another thing you can store in your DB is question/option text and their translations. It would be like the other settings table, except with columns for the country/region.
The database should not be encoding things like what questions the user is asked, which screen to go to next etc. because they have their own place in your architecture.
The only advantage of doing this decision making in your schema is that you can make ad-hoc changes in response to bugs. But you are also more likely to make mistakes doing everything in SQL.
If you find yourself needing to change the UI rapidly (and unable to wait for a code release) you should look at improving your deployment pipeline and also asking if you have a good enough picture of the UI design, business logic and requirements.