There is no one size fits all answer to this and following the GitHub you linked would be actively harmful in my opinion. The specifics of your situation matter greatly.
Totally agree with that. CTO needs to be creative so any "walkthroughs", best practices, etc should be based on logical conclusions coming out of project scope and goals.
Any ways to standardise it are deemed to produce illiterate "CTOs" who follow the notorious saying about a man with a hammer looking at every problem as a nail. There is a fair share of people like this in IT
Your question is way too broad to answer it in few sentences... Normally what I'd do is analyse the project as much as possible (goals, planned growth, market, etc) then build schema with each components challenged with few similar services. Then re-analyse it again from financial perspective and possible technical debt. Then ask to review it someone else to avoid my biases holding me from optimal solution.
From what I see nowadays, it's more like, hey we have a project... Let's do it with AWS it has a ton of cool features!
(substitute AWS with GC, Azure or anything of your choice)
Agreed these will vary greatly org to org, and are bound to be biased, yet having a collection of these lists will help myself and others distill what is needed for a specific org.
So ideally there will be many many lists / recommendations / best practices (with the org's specific situation / requirements) such that I and others can formulate our specific blueprint and start building.
Any ways to standardise it are deemed to produce illiterate "CTOs" who follow the notorious saying about a man with a hammer looking at every problem as a nail. There is a fair share of people like this in IT