I spent my first year as a cloud associate learning things the slow way, mostly by causing small problems and cleaning them up. None of it was in a certification. Here is the list I would hand my past self, the stuff that actually mattered once I was responsible for real infrastructure instead of a lab account. 1. The bill is a map of your architecture I used to think the cloud bill was finance's problem. It is not. The bill is the most honest diagram of your system you will ever get. If a line item is big and you cannot explain it, you do not fully understand your own architecture. Reading the bill taught me more about how our system actually worked, where the data flowed, what ran when, than any diagram someone drew. Learn to read it early. 2. Tag things on day one, not "later" Every account I have seen swore it would add tags "once things settle down." Things never settle down. Untagged resources become unattributable cost and unownable risk, and retrofitting tags across a live account is miserable. Tag from the first resource: owner, environment, team. It costs nothing at creation and saves enormous pain later. This is the single cheapest habit with the biggest long-term payoff. 3. Least privilege is a gift to your future self Early on, broad permissions feel efficient, you are not blocked, everything just works. Then an incident happens, or an audit, or you inherit an account where everything can do everything and nobody can safely change anything. Scoping permissions tightly is annoying in the moment and a relief forever after. Start narrow and widen when needed, never the reverse. 4. "It works" and "it is done" are different My early wins were making something work. What I did not appreciate: working is the easy 80%. Done means it is monitored, it has an owner, it fails safely, and someone other than me can operate it. The gap between working and done is where most incidents live. Now I do not call something finished until I can answer "what happens when this breaks, and who finds out." 5. Idle and orphaned resources are everywhere, and they are your easy wins I was intimidated by cost optimization until I realized most of it is not clever, it is just looking. Unattached volumes, idle load balancers, forgotten NAT gateways, dev environments running 24/7 nobody uses. None of it requires deep expertise, only the willingness to look, and it is the fastest way for a junior person to deliver visible value. Finding and killing waste made me look far more senior than the skill actually required. 6. Read the docs, especially the boring pricing pages The pricing and limits pages are where the expensive surprises are hiding, and almost nobody reads them until after they get burned. Data transfer pricing, service quotas, the difference between stopping and deallocating a VM. The docs are dull and they will save you real money and real outages. Reading the pricing page before designing something is a superpower disguised as tedium. 7. Automate the thing you have done manually three times I wasted early hours doing the same manual tasks over and over because automating felt like a detour. The rule I use now: the third time I do something by hand, I script it. Not the first (might be a one-off), but the third means it is recurring, and recurring manual work is both a time sink and a source of human error at 2am. 8. Incidents are the real curriculum The certification teaches you the happy path. The incidents teach you the system. Every outage I was part of taught me more than a month of reading, about how things actually fail, how they depend on each other, and how to reason under pressure. Do not dread incidents (once they are resolved). Do the postmortem honestly, write down what you learned, and you will compound faster than any course. 9. Ask "why," not just "how" The fastest way to stay junior is to only ever ask how to do the task in front of you. The people who grew fastest around me asked why the task existed, why it was designed that way, what it was protecting against. "How do I schedule this shutdown" is a task. "Why does this environment run 24/7 when nobody uses it at night" is the question that actually saves money and makes you think like an owner. The take Most of what made me better in year one was not technical depth, it was habits: read the bill, tag early, scope permissions tight, finish things properly, look for the easy waste, read the boring docs, automate the repeated, learn from incidents, and ask why. The technical skills came with time. The habits are what I would install on day one if I could. If you are further along, what is the one thing you wish you had known in year one? And if you are just starting, which of these do you already suspect you are skipping? Mine was tagging, I learned the hard way, cleaning up an account where nothing was labeled and no cost could be traced to anyone.