No, they don't. You can't even specify template-level tags in the template.
I think they have very incapable developers on the CloudFormation project. This could have been a game changer, but it's been a source of pain.
For example, they introduced YAML, and !Sub, but you can nest tags, yet, !ImportValue in many cases needs a nested !Sub. So, also, you can't have "$", "{", and "}" characters in the exported name, but they didn't add string templates to functions such as !ImportValue. Total nonsense!
Also, as you've assumed logically, all stack resources need to inherit the tags of the owner stack, but no, you have to do tons of copypasta!
Last, but not least - it's all designed that the templates are stored on S3 - most people use source control. Their other services already support Git - Elastic Beanstalk, CodeBuild, CodePipeline, etc. Why they don't allow Git-hosted templates?!
Anyway, when I see the complexity of my templates to have a basic Magento infrastructure running in VPC, which I've been working on, it's very disgusting. Lots of manual steps if you don't want to have a monolithic template, lots of CLI, and build steps. This is not how things like these should be implemented in 2017!
Lastly, they introduced CloudFormation exports. Okay, decent feature, but not in the real world! So, if you refactor your infrastructure, it becomes a huge pain as you cannot delete exports for some reason - they belong to the stack. So, if I decide to rename or split an export, I need to have an intermediate step, which duplicates the old and the new exports, I updated all importing stacks, to use the new values, and so on. Most AWS resources have "retain" capability - S3 buckets, ECRs, Route 53 records, etc. - CloudFormation exports don't! Honestly, they need to put some more experience and brighter developers on the team!
I think they have very incapable developers on the CloudFormation project. This could have been a game changer, but it's been a source of pain.
For example, they introduced YAML, and !Sub, but you can nest tags, yet, !ImportValue in many cases needs a nested !Sub. So, also, you can't have "$", "{", and "}" characters in the exported name, but they didn't add string templates to functions such as !ImportValue. Total nonsense!
Also, as you've assumed logically, all stack resources need to inherit the tags of the owner stack, but no, you have to do tons of copypasta!
Last, but not least - it's all designed that the templates are stored on S3 - most people use source control. Their other services already support Git - Elastic Beanstalk, CodeBuild, CodePipeline, etc. Why they don't allow Git-hosted templates?!
Anyway, when I see the complexity of my templates to have a basic Magento infrastructure running in VPC, which I've been working on, it's very disgusting. Lots of manual steps if you don't want to have a monolithic template, lots of CLI, and build steps. This is not how things like these should be implemented in 2017!
Lastly, they introduced CloudFormation exports. Okay, decent feature, but not in the real world! So, if you refactor your infrastructure, it becomes a huge pain as you cannot delete exports for some reason - they belong to the stack. So, if I decide to rename or split an export, I need to have an intermediate step, which duplicates the old and the new exports, I updated all importing stacks, to use the new values, and so on. Most AWS resources have "retain" capability - S3 buckets, ECRs, Route 53 records, etc. - CloudFormation exports don't! Honestly, they need to put some more experience and brighter developers on the team!