Why does PK constraint require a separate index when I already have a suitable unique clustered index? This is part of table definition from here:

CREATE TABLE [dbo].[JobItems] (
[ItemId]            UNIQUEIDENTIFIER NOT NULL,
-- lots of other columns
CONSTRAINT [PrimaryKey_GUID_HERE] PRIMARY KEY NONCLUSTERED ([ItemId] ASC)
);

CREATE UNIQUE CLUSTERED INDEX [JobItemsIndex]
ON [dbo].[JobItems]([ItemId] ASC);


This is some legacy design, so please don't ask "why". Anyway when I look up the list of indexes I see that there're two indexes - one of them is JobItemsIndex and the other is PK-GUID-HERE and they are both for JobItems table.

My question is...

Why is there a need for a separate index to maintan the PK when I already have JobItemsIndex which is unique and includes the very same column and so suitable for maintaining the PK constraint?
It doesn't need a separate index. It's only done that way because you've actually told it to be in the script. You could do this with the same functionality:

CREATE TABLE [dbo].[JobItems] (
[ItemId]            UNIQUEIDENTIFIER NOT NULL,
-- lots of other columns
CONSTRAINT [JobItemsIndex] PRIMARY KEY CLUSTERED ([ItemId] ASC)
);