Cloud Workflow Reference
Summary
This note is a lightweight reminder of the checks and workflow stages that often support small cloud deployments and operations work.
Example workflow pattern
Use a quick sequence like this before and after a small infrastructure or app change:
# confirm you are in the expected repo and workspace
pwd
git status
# validate IaC before changing anything
terraform fmt -check
terraform validate
terraform plan
# apply only when the plan makes sense
terraform apply
# then validate the result
terraform state list
curl https://example-app-urlIf the work is provider-side rather than pure Terraform, the same logic still applies:
# confirm acting identity and scope
aws sts get-caller-identity
az account show
# inspect the resource you expect to exist
aws ec2 describe-instances
az webapp list --output tableWhen to use this note
- when you need a fast pre-change or post-change cloud checklist
- when you want to sanity-check scope, access, and validation before acting
- when you need a broad reminder without opening a provider-specific guide
Planning and scope checks
| Check | Purpose |
|---|---|
| intended environment is correct | avoid changing the wrong scope |
| acting identity is clear | avoid permission confusion |
| expected result is defined | know what success should look like |
Deployment checks
| Check | Purpose |
|---|---|
| plan before apply | inspect change intent |
| validate after deploy | confirm resources and app behaviour |
| review logs after change | confirm runtime visibility |
Validation examples
Use small checks that match the layer you changed:
# infrastructure exists
terraform state list
# service responds
curl https://example-app-url
# runtime logs are visible
aws logs describe-log-groups
az monitor app-insights component show --app APP_NAME --resource-group RG_NAMEOperations checks
| Check | Purpose |
|---|---|
| IAM scope is sensible | reduce risk and confusion |
| monitoring exists | make troubleshooting possible |
| rollback or teardown thinking exists | support safe change and cleanup |
Notes
- this note is intentionally broad and platform-agnostic
- the point is to support safer cloud habits, not replace AWS or Azure-specific reference later
- cloud work gets easier when deployment, access, and visibility are thought about together
- even broad cloud notes become more useful when they include one or two repeatable command patterns
Common mistakes
- applying changes before checking scope and acting identity
- treating deployment success as proof that monitoring and operations are ready
- changing cloud resources without thinking about rollback or teardown