Since you'll most likely be part of setting up the deployment pipeline, you have to understand to some extend various git flows. You might end-up consulting developers on how to build applications that will run on a docker container, what are the best practices and what pattern the app must follow (e.g. circuit breaker) in a micro-services environment.
You surely will want to automate some management. So apart from DSLs like terraform and configuration management systems (puppet, chef, saltstack, ansible) you will have to write some API here and there, an application tailored around the need of your systems. This application might end up being written in python, ruby, golang or C.
Now, consider that you have build the CI/CD, the orchestrator, alongside the entire pipeline and logic to drive an application from staging to production. You'll most likely be on call and you'll have to deal with networking issues at TCP, HTTP or DNS level, load balancing, autoscaling, etc. You might have a say on that query which is too heavy because the data is un-indexed because, well brings down the database every now and then.
There is no role I can think of in a modern institution which has the breadth of technologies that an SRE (or DevOps engineer as they are often called) will have to gain expertise.
In short you have to be: A medium-level programmer in terms of concepts, have networking experience, learn dozens of new tech, face ever-evolving problems eventually at scale, design end-to-end systems, debug applications others written sometimes without having context, understand trade-offs of new tech stacks only to explain it to others (which might end in a PITA due to the back-and-forth but you'll eventually end up knowing lots of things you didn't ever thought about).
If you like all that, then an SRE role is ideal IMO even in medium to big corps.
NOTE: The role could be called SRE, DevOps engineer, Infrastructure Engineer and/or quite a few other things depending on where you work. Responsibilities tend to overlap significantly though.