The Support Engineer's Cloud Toolkit

Cloud Troubleshooting & Support

Chapter 1 · The Support Engineer's Cloud Toolkit

Course 1 built the conceptual foundation — every major service category, framed cross-provider throughout. This course turns the troubleshooting instincts developed along the way into deliberate, practiced skill. This first chapter starts with the actual tools used day to day.

Console vs. CLI vs. API — Three Ways In

Every provider offers three ways to interact with resources: the web console (visual, good for exploration and one-off tasks — cloud1-2's free-tier sandbox advice assumed exactly this), the CLI (aws-cli, az, gcloud — scriptable, faster for repetitive tasks, essential for automation), and the underlying API that both the console and CLI actually call underneath.

The console is a UI, not a separate system
Understanding that the console is just a visual layer over the same API the CLI calls directly explains why a change made in one shows up identically in the other — they're two interfaces to one underlying system, not two separate ones to reconcile. Worth keeping in mind if the CLI feels intimidating at first: it isn't doing anything fundamentally different from what clicking through the console already does.

The Three CLIs, Compared

AWSAzureGCP
CLI nameaws-cliazgcloud
Initial setupaws configureaz logingcloud init
Example commandaws ec2 describe-instancesaz vm listgcloud compute instances list

Exact syntax differs, but the underlying pattern is reassuringly consistent once recognized: <cli> <service> <action>, a noun-verb structure shared across all three.

Authentication for CLI Tools

Revisiting cloud1-6's IAM material specifically for CLI access: access keys (AWS), service principals (Azure), and service accounts (GCP) are the CLI-specific credential types. The same hardcoded-credential warning from cloud1-6 applies doubly here — a credentials file sitting on a support engineer's own laptop is a genuinely real risk if that laptop is ever compromised, or if the credentials file is accidentally synced or backed up somewhere it shouldn't be.

Why the CLI Matters for Support Work Specifically

  • Scriptability — checking the same thing across many resources or accounts at once, something console clicking simply can't do efficiently.
  • Filterable, saveable output — CLI output can be piped, filtered, and saved for documentation or escalation — this site's own bash_intermediate_07 chapter on jq applies directly here for JSON output.
  • Reproducibility — a documented CLI command in a support ticket is exact and unambiguous. "I clicked around in the console and fixed it" isn't reproducible or verifiable by anyone reviewing the ticket later.

Reading Architecture Diagrams

Each provider has its own standard icon set (AWS Architecture Icons, Azure Architecture Icons, GCP's own set) — not identical, but sharing the same visual language: boxes for resources, arrows for data/traffic flow, dotted boundaries for network boundaries (VPCs/subnets, cloud1-5). Being handed an unfamiliar customer's architecture diagram and quickly identifying which piece is likely failing, based on the reported symptoms, is a genuinely practical skill — directly drawing on cloud1-5's networking material and cloud1-8's monitoring material for deciding where to check first.

Common Support Workflows — A Practical Starting Toolkit

  • Resource inventory — listing all resources of a given type or tag to confirm what actually exists versus what a customer believes exists (cloud1-9's tagging material).
  • Point-in-time config snapshot — capturing a resource's current configuration before making any change, as a rollback reference.
  • Cross-referencing a ticket's resource ID against current state — a genuinely common first step, confirming the resource still exists and hasn't already been remediated by another automated process.
Your own laptop's CLI credentials are a real security responsibility
Directly echoing cloud1-6's and pipelines1-5's hardcoded-credential warnings — now applied to a support engineer's own workstation rather than application code: credentials sitting in a CLI config file are a genuine target if that machine is compromised. Scoped-down, task-specific credentials (rather than broad admin access), MFA, and regular rotation all reduce this risk meaningfully.

Hands-On Exercises

Exercise 1

Explain why a CLI command documented in a support ticket is more useful to a colleague reviewing that ticket later than a note saying "I clicked through the console and fixed it."

📄 View solution
Exercise 2

You're handed a diagram showing a load balancer, two web server icons behind it, and a database icon inside a separate dotted boundary. Users report "intermittent timeouts." Using Course 1's material, identify which piece you'd check first, and why.

📄 View solution
Exercise 3

Explain the real security risk of CLI credentials stored on a support engineer's own laptop, and describe at least two practices that reduce that risk.

📄 View solution

Chapter 1 Quick Reference

  • Console/CLI/API — three interfaces to the same underlying system, not separate systems
  • aws-cli/az/gcloud — different exact syntax, same noun-verb pattern (<cli> <service> <action>)
  • CLI credentials (access keys/service principals/service accounts) carry the same hardcoded-credential risk as cloud1-6, now on a support engineer's own machine
  • CLI advantages for support work: scriptability, filterable/saveable output, and — critically — reproducibility in tickets
  • Reading architecture diagrams: boxes = resources, arrows = traffic flow, dotted boundaries = network boundaries (cloud1-5)
  • Reusable workflows: resource inventory, point-in-time config snapshots, cross-referencing ticket resource IDs against current state
  • Next chapter: Diagnosing Connectivity Issues — a real troubleshooting flowchart built on cloud1-5's networking material