Normal constraints (check constraints) will not work in your case because when checking the correctness of the inserted value of one attribute you need to view the attribute values of another table. And to identify the connection between them, you need a separate request. But requests to insert into the conditions of the limitations of the DBMS as a rule do not give.
You can write a trigger that will do all the necessary checks (in it, how many you want queries you can perform), triggered by inserting / changing values in the ResultsTable table. If the values are not correct, then we throw an exception. But here it is important that your database supports triggers. SQL-Server, as I recall, supports.
You can also make a unique Variants index (QuestionId, Id) and set the foreign key on the ResultsTable (QuestionId, VariantId) on it. It is more universal.
But first of all think about the structure of your base. From each entry in the Variants table, you can get a QuestionID. That is, for each record from the ResultsTable, then a QuestionID is available (via Variants), and you push another 1 QuestionID there. And it should coincide with the QuestionID of Variants. This is a duplication of data. Sometimes it is justified (for example, for performance reasons), but most often it only brings integrity problems and increases the size of the base. The easiest way to remove the QuestionID from the ResultsTable and all problems will be solved. However, it is necessary to rewrite database requests from the application using it.
