A primary key <> a clustered index. By default, when you create a primary key, SQL will build a clustered index on that key, assuming there is not already a clustered index. But, you can specify a nonclustered index for the PK.
e.g. you can write:
ALTER TABLE Production.TransactionHistoryArchive
ADD CONSTRAINT PK_TransactionHistoryArchive_TransactionID PRIMARY KEY CLUSTERED (TransactionID);
but you can also specify NONCLUSTERED on the ADD CONSTRAINT line.
Using a good clustered index can speed up data retrieval or searching in the same order as the CI. Microsoft recommends that all tables have a CI. But that need not be the PK. The PK should be a good, unique business key or surrogate key. The CI can be on different columns (and if not unique, a unique-ifier is added).
Too many shops (looking at my own!) use an IDENTITY as the PK and the CI which makes sense in some scenarios (e.g. DW apps) but not so much in others.
Since you’re just learning about it, separate the two ideas and keep them separate. Then optimize your table, choosing the best CI and PK for business purposes. It’s good to settle this quickly though, since the cost of changing either goes up as the table grows.
One other thing to keep in mind: if the table has a CI (actually I should say if your table is a CI, since tables are either CIs or heaps), then all other indexes record the CI key columns and use a key lookup to get other columns. that’s one reason why integer identity columns are popular – they keep the index entries narrow and hence the b-tree shallow – both good things.
This can be outweighed by other factors though. If a table has lots of INSERTs, it can develop a “hot spot” at the end, increasing contention. One solution is to use a GUID for the CI key. But this is not a general recommendation. It depends on your unique situation.