It is rare that I contradict Pat and I usually duck afterwards. But sometimes I have to point out a fine point in the issue of pragmatic design.
At least in theory it is not necessary to have a PK on every table. It has very serious implications to say that, though. Pat is absolutely right to say it is not recommended. The reasons have been touched on in earlier posts.
In a one-to-many table, the one side ABSOLUTELY must have a PK. Without it, you have no relationship. Period.
If the many-side table doesn't have a PK, it means you cannot so easily select a single row from the many-side table for an update of that one row. But if it at least has an FK corresponding to the right PK from the one-side table, it will work in parent/child queries (or parent/child forms) and still will be normalized. Relational integrity could be declared and would work.
Now, if the first many-side table is ITSELF a parent in its own one/many setup in a three-tier cascade, then YES the "middle" table ALSO needs a PK as a normalization issue. And in that case, the grandchild table is the ony participant that could get by without a PK. With, as noted, the same restriction on selective updates and the same issues regarding relational integrity.
There IS such a thing as a compound PK such that the FK and some other field in combination have to be unique. The many-side table can have a valid compound PK comprised of the FK and something else. Hint: The shortest possible "something else" that retains uniqueness would be the best choice. But it MUST retain uniqueness when taken in combination with the FK. AND in fact, if such a candidate exists without the FK as a compound key participant, that's more better, I gawrontee! (sorry, lapsed into my Cajun accent...)
Now, here is the issue that would trump everything your instructor said. IF you have a requirement to be able to selectively update a single record from the many-side table and have no candidate keys for the compound PK, add the ID field as an issue in program design necessity, because in that case, you have a requirement that dictates the presence of a PK.
Here's why: The issue of a unique update requirement implies that there will be some record in that table that is uniquely identified by a PK, whether single or compound. Which IS a normalization issue, because that ability to uniquely identify a record based on its PK is another way of saying that all fields in a given record depend on all keys of that record and nothing else. This is a property-based definition rather than an "eliminate xyz by moving to another table" definition. And THERE is your loophole. Note that if a unique update of the many-side table's records is NOT required, then you do not need that PK.