CanDeactivateGuard is used in CrisisCenterRoutingModule which is part of CrisisCenterModule which is lazy loaded by AppRoutingModule (loadChildren: 'app/crisis-center/crisis-center.module#CrisisCenterModule').
q: Why should CanDeactivateGuard be declared in AppRoutingModule providers? why not to CrisisCenterRoutingModule providers?
guide answer: We also need to add the Guard to our main AppRoutingModule providers so the Router can inject it during the navigation process.
my (original) comment
AppRoutingModule seems to need to know in advance (at least for lazy loaded modules) the CanDeactivate guards used classes. It's odd why this does not apply for e.g. CrisisDetailResolve which is a service too and has the same configuration parent.
the final answer
Well, it seems that indeed CanDeactivateGuard could be provided by CrisisCenterRoutingModule too instead of AppRoutingModule.
Now the question is why then the guide pointed AppRoutingModule as the one to provide CanDeactivateGuard?
The answer I guess is that the CanDeactivateGuard is a service useful to any module and because lazy loaded modules have their own root injector this means it would be created an additional instance of CanDeactivateGuard for any lazy load module that would provide it too. CanDeactivateGuard has no state so it's useless to have more than one instance of it.