I see here 2 questions:
What key constraints to enforce?
Guest and Event make up a Guest_Event entity, that may (potentially) exist without a Setting. So in Guest_Event table you'll enforce constrains on 2 columns Guest_ID and Event_ID.
One Guest_Event object may have several Setting objects. So this link should be enforced as well.
Another question is How to define keys for Guest_Event and Settings objects: as 2-3 separate columns or a single column?
It depends on how the application will be using these tables. Single column ID for Guest_Event and Setting will do if you'll be extracting these IDs and then reusing them in Where clause.
However if you need to get a Setting and application always knows Guest_ID and Event_ID, then getting individual Setting ID is an unnecessary step.
Covering indexes (ones including all key columns in all combinations) will help your performance, if you have enough space to store them and time to update them.
Your schema has no object specific data in Guest_Event table: if Guest_Event table has only keys, then it is not needed: you can use Settings table to track Guest_Event by using Setting like "G_E Instance Number ## Exists".
I suggest looking at this "Full schema" and removing parts, that your application will not use.
Order of the columns represent how often it will be used in filters: more often - more to the left.
CREATE TABLE guests (guest_id int PRIMARY KEY);
CREATE TABLE events (event_id int PRIMARY KEY);
CREATE TABLE guest_event (
guest_event_data varchar (200),
PRIMARY KEY (guest_id, event_id, guest_event_id),
FOREIGN KEY (event_id) REFERENCES events (guest_id),
FOREIGN KEY (guest_id) REFERENCES guests (event_id),
KEY (event_id, guest_id, guest_event_id),
KEY (guest_event_id, guest_id, event_id)
CREATE TABLE settings (
PRIMARY KEY (guest_id, event_id, setting_id),
FOREIGN KEY (guest_event_id) REFERENCES guest_event (guest_event_id), KEY (event_id, guest_id, setting_id)
KEY (event_id, guest_id, setting_id)