Aside from implementing FedRAMP controls as it relates to these servers (look up FedRAMP’s system security plan template for these controls to get a better idea of what these are) the role would likely involve speaking to assessors from a 3PAO and the FedRAMP PMO and demonstrating that the controls are implemented.

Yes - it is tedious and a drawn-out process that will last many months (could be more if the org is far from FedRAMP-Ready) but may be a great learning experience as well.

FedRAMP's tediousness really depends on your organizations level of adherence to a well-governed, mature security, risk and compliance program. If you are a startup that's just been building stuff and selling it to customers, FedRamp can be quite an effort.

Like most external compliance, say PCI, HITRUST, FedRAMP, etc. It's all based on (some combination) if what are your current practices (documented and verified by a 3rd party), are the controls actually meeting our requirements, have these controls been tested (3rd party w/ documented minimum test cases), and when you put this all together, are you meeting our requirements. FedRamp, as do many others, have a continuous compliance requirement, so get used to working with 3rd party approved testers and auditors.

If your organization is relatively young, with a minimal perimeter and small in size, these probably isn't a very heavy lift. If your organization is older, with lots of people and diverse / redundant technology, this could be more complicated.

From a modern software perspective, the technology itself isn't the hard part. It's creating processes that are auditable and consistent, and making sure they are used. It can be a bit of a cultural shift and it can impact lots of people. The problem with modern software development is that there is this myth that engineers get what they want, or they go elsewhere. In my experience, people need to understand why they are being asked to change and that governance / compliance aren't dirty words, they lead to better, more secure products / companies. The one caveat is that if you have teams that only want to right functional code / service technical debt, and they don't care about where the company wants to go and why, this could be a problem.