3ton

Как указал iljaGolubev проще всего и наверно правильней если у вас лишь один такой урл.
Если же их много, то вы скорей всего забудете некоторые либо устанете их тянуть в процессе разработки. Тогда проще после описания конфига описать цикл для блокируемых путей

if(!defined('YII_DEBUG') || YII_DEBUG === false)
{
    $disallowRoute = ['test','test/mode2','result2'];
    foreach($disallowRoute as $route)
    {
        $config['components']['urlManager']['rules'][$route] = 'error/404';
    }
}

В свое время мы столкнулись с такой же проблемой - разделить монолит на фронт и бэк отдельно.

Пошли простым путем: выдали на бэке отдельно методы API для фронта, а с фронта работали с ними из CMS, в которой написали свои расширения и ими формировали функционал реализованный ранее лапшекодом.

В дальнейшем фронт был передан третьим лицам на продвижение. В итоге мы сняли с себя этот груз и разграничили таким образом доступ к приватным данным.

Каждый выбирает свой способ постичь дзен в выбранном языке. Но у большинства одно и то же направление. Мой подход не сильно отличается от остальных, но есть свои моменты.
1. Во первых лучше всего вспомнить что вы раньше не имея навыков программирования желали сделать и поставить это своей целью. Описать все это где-то на электронном или бумажном носителе, так как если вам на данный момент кажется что все предельно ясно и вас ночью разбудить и вы все это наизусть произнесете, будьте уверены что после кучи часов искания как вам реализовать тот или иной момент вашей задачи вы будете помнить лишь очертания задачи, а тонкости уже не будут такими ясными и результат будет меняться...
2. Вам явно не стоит пытаться реализовать что-то стандартное которое везде описывают, так как вы научитесь просто читать статьи и туториалы и копировать строки оттуда в свой код, вы извините, но человек существо ленивое и почти всегда выбирает путь наименьшего сопротивления.
3. Даже реализовав проект вы получаете навыки постановки себе задач и их реализации, но вы все еще остаетесь начинающим программистом. дело в том что за свои почти 15 лет в РНР я не раз встречал работу РНР кода отличающуюся от ожиданий(и даже документации, либо же недокументированное поведение определенных комбинаций кода), а это уже - опыт...
4. изучать фреймворки это клево и нужно, но пытаться сразу выделить себе какой-то фреймоврк и строить задачи на нем - не верно, вы научитесь лишь его функционалу, но понимание того как это делает за вас фреймворк - останется черным ящиком. а если вы посмотрите логи обновления версий фреймворка, то вы увидите сколько там происходит изменений и обновлений в логике, что уже означает - мало того что вы будете принимать на веру то что в черном ящике, так еще и от версии к версии это может совсем не так работать как вы приняли на веру в момент изучения...

поэтому подведя итоги скажу так
- поставьте задачу из того что вам хотелось, но пусть это не будет чем то сложным вроде сервера игры. к примеру если вы когда-то что-то коллекционировали, то попробуйте создать менеджер коллекции, и пусть он будет иметь админскую часть для наполнения инфы и авторизации, а так же клиентскую часть для ее отображения. И поставленная задача должна выполняться в ее первоначальном виде, так как иногда будет казаться что лучше ее изменить чтоб облегчить свою участь, но этим вы ухудшаете свои навыки - терпеливость, настойчивость и умение находить решение редкоиспользуемых моментов.