1. Learn a programming language first. Pick something common. Ecosystems are more important than the quality of the language. If you feel overwhelmed by choice learn Python. The ideal learning path is high-level -> low-level -> low-level (advanced) -> high-level (advanced). You want the language to get out of your way at first so you can learn concepts, then get in your way as you learn how things really work, and then back out as you learn real software development. Learning version control first will feel completely unmotivated without knowing why the tools the way they are.
2. Absolutely 100% learn Linux. The best infra people have a strong strong background in sysadmin work. And learn networking through the lens of the kernel/low level userspace. Don't try to learn network protocols in a vacuum, learn how they're actually used on real systems.
3. From this point skip right to IaC. You are at the point where this will make the most sense. And unless you have quite the setup this is when you're gonna learn a cloud provider. Pick AWS. This isn't a bias toward them -- knowing AWS will make learning other clouds easier, the reverse isn't true. And tooling, guides, and documentation for AWS is more plentiful. Explore using the console but don't do anything except play around. Assembling the Cloudformation/Terraform will teach you much much more about how the pieces fit together.
4. Now learn CI/CD, and you'll find yourself reaching for containers here because it's such a huge pain without them. Now you have a real motivation to learn them that isn't contrived. Once it "clicks" you'll understand why you might want to deploy other things with it.
6. Don't bother learning "devops the process" -- it's worthless, nobody agrees what it even is, and every company will do it differently anyway. You want your "knowledge" about the process to be as rich as the flavor in a La Croix. All these processes are at their best when everyone only vaguely knows what they are because any sort of strict adherence only makes you lose sight of your real goals.
7. Do not learn k8s until the very end. It is literally the final boss that combines all the other knowledge you acquire in your devops journey and you genuinely cannot understand the architecture, the tools, and decisions until you experience the pain points of not using it.
8. If you can swing a job as a junior then don't bother to learn how to run production systems, you will learn so much better and faster on the job than anywhere else. Have a "homelab" running some semi-production services to play around with and talk about in the interview but be ready that the big leagues will be a lot more involved. Once you are reasonably self-sufficient at your job and ready to move from maintainer to architect then look toward sre books.
This will get you ready to work at shops in the cloud. If you want to do on-prem work it's a different path.