[What is the nature and description of the request?]

When provisioning a system using cloud-init, the customer scripts that need to be run once the bootcmd contents from user data are completed. If they're run before userdata, it's too early for them to be effective, and attempting to use bootcmd in the cloud-init configuration won't occur if the user data includes any bootcmd content.

This specific example is yum commands that cannot run during the config stage and must be run during the init stage in order to run because yum settings are not yet defined prior to the start if the init stage.

More details from the customer:
*******************************
1.  My script to configure the yum variables needs to run during the Network boot stage (I will rely on the terminology from this document when referring to the boot stages: https://cloudinit.readthedocs.io/en/latest/topics/boot.html).  The bootcmd is run during the Network boot stage, and so I should be able to use this instruction to run my script.  However, the challenge is that I need to be able to bake this configuration into an image, by placing a configuration file in /etc/cloud/cloud.cfg.d.  If the user specifies a bootcmd instruction in their user data, my script won't be run, which is not desirable.
2.  The reason the script cannot be run during the Config stage is that the Config stage includes other steps that access the instance's yum repositories (e.g., the user might have a yum install in their runcmd instructions) and there would be no way to guarantee that my script is run before these steps.
*******************************

The customer is currently using a workaround I found on serverfault.com: https://serverfault.com/questions/871328/start-service-after-aws-user-data-has-run

[Why does the customer need this? (List the business requirements here)]

Being able to ensure the applying user-data still allows for content to be run as part of bootcmd is essential for many use cases for provisioning. Working around the issue by tinkering with the systemd service files is unnecessarily complicated and prone to issues, as well as being unsupported.

[How would the customer like to achieve this? (List the functional
requirements here)]

A way to specify commands be run as part of bootcmd that aren't overridden by user data, while still permitting user data.