Давайте разберем кейс. Основная сложность экзамена PMP в том, что в большинстве вопросов нет неправильных ответов. Всегда в выборе есть несколько логичных вариантов, и лишь один оказывается "более правильным", потому что учитывает больше факторов или отражает процессный подход PMI. Именно за это я люблю этот экзамен - он отличный индикатор знаний и зрелости проектных менеджеров.
Сейчас можно найти массу современных симуляторов для подготовки. В то время, когда я сдавал PMP, был один-единственный симулятор, который можно было достать только по редким торрент-ссылкам, всегда в устаревшей версии. А готовились мы в основном по книге Риты Малкахи "PMP Exam Prep" - настоящему классическому пособию, по которому десятилетиями учились будущие PMP-сертифицированные менеджеры.

Я бы не хотел уводить дискуссию в плоскость "теория vs практика". Конечно, в реальных проектах бывают нюансы, но на уровне зрелого понимания редко встречается что-то, что постулируется в методологии PMI и при этом полностью расходится с практикой.
Проектный менеджмент во многом стоит на управленческой культуре. И то, что иногда кажется избыточным или неприятным на первых порах, чаще всего так воспринимается не потому, что это "неправильно", а потому что сама культура управления проектами еще только формируется или не закреплена в компании.

Разбор:
A - кажется очевидным, но неверно: Change Control Board нужен только при изменении baseline (scope baseline, cost, schedule). Здесь этого нет.
B - допустимо, но если цель уже явно прописана в уставе, то этот шаг избыточен.
C - наиболее правильный ответ по PMI: требование согласуется с целями и не нарушает треугольник ограничений, значит, оно принимается без запуска CCB.
D - провокация, на которую клюнут многие менеджеры из сервисных компаний (upsell!), но это уже выход за рамки управления проектом и больше про бизнес-девелопмент. Который опять в контексте похожих реальных кейсов чаще работает в минус. Компания ничего не теряет, и не занимается благотворительностью,е сли принимает требования заказчика и может вписать их в изначальный проектный треугольник. Это как раз то, что и должен делать профессиональный менеджер, и что в последствии обеспечивает рост внутри клиента за счет професиональной работы. Upsell без причины - убивает рост.
E - рабочее действие в плане коммуникаций, но PMI требует сначала понять - принимается ли требование в рамках устава.
F - похоже на agile-практику, но тут фокусировка на управленческом процессе, а не на прототипировании.