I'm starting a new infrastructure engineering role focused mainly on Terraform and AWS. I've been doing cloud engineering for several years, but my current team is small, so I've mostly worked in a fairly isolated environment. I have a degree in Cloud and Network Engineering along with the relevant certifications, and I'm excited to learn how larger, more experienced teams operate.
I'm curious about a few things:
1. How much do you use the AWS CLI in your daily work? I mainly use it for scripts, while persistent changes go through Terraform or CDK and quick checks sometimes happen in the console. Do experienced engineers memorize lots of commands, or do you regularly rely on built-in help and documentation?
2. How much time do you spend reading documentation to choose an architecture, understand a service, or find the right syntax? I sometimes imagine experienced cloud engineers already know every configuration and design pattern, but I assume there's still plenty of research involved.
3. How common is AWS CodePipeline for CI/CD? GitHub Actions with OIDC has worked well for my projects, although I can see how built-in approvals and governance features might be useful in some organizations. I'd appreciate hearing what tools and workflows larger teams actually use.
5 Answers
Documentation is a normal and significant part of the job. Even experienced engineers regularly check service documentation, examples, API references, and sometimes source code. The amount decreases for familiar systems, but it goes up whenever you’re learning a new service or feature. The important skill isn’t knowing everything from memory; it’s knowing how to find reliable information and evaluate the design options.
In a mature environment, you may see a split between tools: Terraform for infrastructure, Python or SDKs for automation, and terminal-based workflows for testing and operating systems. Some teams barely use the AWS CLI directly because their scripts and internal tooling handle most tasks. Others use it constantly for investigation and one-off operations. Ask your new team what is considered safe for production changes and what must go through the normal review process.
CodePipeline is very dependent on the organization, but a lot of engineers find it awkward compared with other CI/CD platforms. GitHub Actions, Jenkins, Bamboo, GitLab, or internal tooling may be preferred when the team already has expertise there. The specific product matters less than understanding the underlying concepts: artifact management, identity, testing, approvals, promotion between environments, rollback, and deployment security.
Helpful command-line utilities are worth learning, especially identity and account-context checks, but nobody realistically remembers every AWS command accurately. Keep reusable snippets, use command help, and verify anything that could affect production. AI-assisted command generation can speed things up, but you still need enough AWS knowledge to review the command and understand its consequences.
The CLI is a daily tool for most infrastructure engineers, but that doesn’t mean memorizing every flag. Learn what the services and commands are capable of, remember the handful of commands you use constantly, and look up the rest. Terraform is usually better for persistent infrastructure changes, while the CLI or SDK is useful for automation, diagnostics, and operational tasks. The console is still handy for exploration and explaining things to teammates.
That’s reassuring. I use the identity check frequently, but I definitely still look up most other commands rather than pretending I remember every option.