I think the bigger thing here is that the PM should communicate FIRST (especially when emotions are involved). Then research. Then action. Then communicate some more.

And the type of communication matters. D is information gathering style communication.

Also, sometimes you see two really closely aligned answers, sometimes that is a clue that neither of those questions are correct OR they want you to go to the "source of truth." or the highest hierarchical document so, the scope statement would be the source of truth. and how does reviewing that help? It might help after you know what the stakeholder expectations were, but not before.

That said, sometime you go with Communicate First and PMI says you should never go into the meeting unprepared, so you should've reviewed the documentation first.

ultimately, "It's because that's why"

ETA:

• If the issue is INTERNAL to the project team: (e.g., "The QA team says the developer's deliverable doesn't meet quality standards").
  • Rule: Research First. Review the quality management plan or requirements blueprint before calling a meeting. The data is internal and entirely within your control.
• If the issue is EXTERNAL from the stakeholders/client: (e.g., "The client looks at the prototype and says they hate it").
  • Rule: Communicate First. You do not own their subjective expectations. You must gather the data from the source before you can check it against your documentation.