Simple can be deceptive. What looks simple is a single table with a single field with multiple values. However, since relational databases don't directly support that construct as it violates first normal form (every field must be atomic), it requires VBA coding in an unbound control to make it happen. Once you have gone through the trouble to make it happen, you then run into the trouble of trying to work with it where you now have to take the multi-valued field apart (again with VBA) to do anything with it.
The two table solution which properly stores the 1-many relationship, looks more complex but in reality is handled without any coding at all if you can live with showing the many-side data as a subform. If you want to show the many-side data "flattened" as checkboxes, you're back into the VBA business but here the problem is limited to the one form where you display and update the data. Any analysis can still be done with queries.
Another option is to store some number of individual fields that are populated from checkboxes. This is a compromise that caters to the data entry/display at the expense of the analysis.
And a final option is to promote the choices so that rather than grouping them in a single question, each becomes its own y/n choice. If you can live with this, this is actually the simplest solution.
The problem is that without significantly more knowledge regarding your application, it is hard to say which solution will be most appropriate.