How do you tie in to version control?
How do you QA this? (Can it be QA'd locally?)
Would you have unit tests for serverless code? E2E tests?
How would you catch/diagnose a more junior engineer making an infinite loop of events? Would this potentially bring down production or eat the budget?
> How do you tie in to version control?
You're probably talking about the infrastructure definition? Infrastructure-as-Code (e.g. AWS CloudFormation) works quite well and can easily be put under version control.
> How do you QA this? (Can it be QA'd locally?)
For AWS there are projects like the AWS SAM CLI (https://github.com/awslabs/aws-sam-cli) which try to offer the ability to run your serverless application locally, but I believe such approaches are fundamentelly flawed once your application reaches a certain complexity, as I believe such projects will never be able to re-implement all features and services made available by the Cloud provider.
What works well for us is to simply have QA environments spun up in addition to the productive ones. Once you got the infrastructure codified properly that's quite easy. The biggest downside is that it, depending on your architecture, might take some time to provision, so it's not as instant as if you'd run it locally. And you need internet access of course.
> Would you have unit tests for serverless code? E2E tests?
Yes and yes. Actually I see no reason why you'd want to handle test coverage differently from traditional applications.
> How would you catch/diagnose a more junior engineer making an infinite loop of events? Would this potentially bring down production or eat the budget?
Running code during development should never be able to affect production. For AWS the way to go is to use separate AWS accounts for production and testing/QA. You could even go so far to give each engineer his own account.
Regarding catching and diagnosing infinite loops, it all comes down to monitoring: Monitor how the cost evolves and other metrics of interest (e.g. the number of invocations of your serverless functions) and have automatic notifications once certain thresholds are crossed. Additionally limiting the maximum concurrency of serverless functions for non-production accounts might help to avoid things getting out of control too fast.