• Primary keys: STUDENT → RollNo; PROJECT → ProjectNo; PROJECT-ASSIGNED → Registration_ID.
• Foreign keys in PROJECT-ASSIGNED: Registration_ID (→ STUDENT) and ProjectNo (→ PROJECT).
• Alternate key: Registration_ID in STUDENT — also unique per student, but not chosen as the primary key. …

a) Primary key of each table

A primary key must be unique and non-NULL for every row. Scan each table's data:

(If the school ever allowed one student to work on several projects, Registration_ID alone would repeat, and the composite key (Registration_ID, ProjectNo) would be needed. With the given one-project-per-student data, Registration_ID suffices.)

b) Foreign key(s) in PROJECT-ASSIGNED

Both of its columns point at rows of other tables:

• Registration_ID → references Registration_ID of STUDENT
• ProjectNo → references ProjectNo of PROJECT

That is exactly what makes PROJECT-ASSIGNED a linking table: every value it stores must already exist in the parent tables (referential integrity).

c) Alternate key in STUDENT

Yes — Registration_ID. STUDENT actually has two candidate keys: RollNo and Registration_ID. Check the data: IP-101-15, IP-104-15, CS-103-14, CS-101-14, CS-101-10 are all different, and a registration ID identifies exactly one student. Since RollNo was picked as the primary key, the remaining candidate key — Registration_ID — is by definition the alternate key. (Name, Class, Section cannot be keys: two students could easily share any of them.)

d) Can a user give RollNo a duplicate value?

No. RollNo is the primary key of STUDENT, and a DBMS enforces uniqueness (and NOT NULL) on the primary key automatically. This is how the table is declared and what happens on the attempt:

CREATE TABLE STUDENT (
    RollNo          INT PRIMARY KEY,
    Name            VARCHAR(30),
    Class           VARCHAR(5),
    Section         INT, …