Ways in: console, CLI, SDKs and infrastructure as code

Three doors, one API

Everything AWS offers is an API, and the console, the command line and the SDKs are three front ends onto it rather than three different systems. That is worth holding onto, because it turns a vague question about "the best way to access AWS" into a concrete one: where does the call come from? A person exploring gets the console. A shell script or a one-line administrative task gets the AWS CLI. Code that already exists in Python, Java, JavaScript, .NET or Go gets that language's SDK, so failures arrive as ordinary exceptions the program can already catch.

The reason a question about an unattended nightly job is never answered by the console is not that the console is bad, it is that a person has to be awake. And the reason it is not answered by shelling out to the CLI is subtler and is what the question is usually testing: you would be parsing output shaped for a human, you would lose typed errors, and you would have added a binary that must be installed and kept in step with the program.

$ aws sts get-caller-identity    "Arn": "arn:aws:iam::111122223333:user/reporting"$ aws s3 ls s3://reports-prod/2026/2026-08-01 04:12:07      18234 daily-summary.json# the nightly job makes the same calls through an SDK

Infrastructure as code, and the service that only watches

Clicking through the console three times produces three environments that are almost the same, and "almost" is where the week-long production bug lives. Infrastructure as code replaces the memory of what someone clicked with a file: AWS CloudFormation takes a template, creates a stack from it, and creates the same stack again from the same template. Because the template is a file, it goes into version control, gets reviewed in a pull request and can be diffed when something changes. The AWS CDK sits one level up and lets you write that template in a programming language, synthesising CloudFormation underneath.

The pairing the exam tests here is CloudFormation against AWS Config, and the two verbs are the whole answer. CloudFormation BUILDS resources from a description. Config WATCHES resources that already exist, records how they were configured over time and evaluates rules against them. Config would have told you the three environments had drifted apart; it would never have created them.

How much of it stays yours

AWS Elastic Beanstalk is the one that gets missed, because it sits between two things candidates already know. You upload an application package on a supported platform and Beanstalk provisions the instances, the load balancer and the scaling policy for you — but the resources it creates are ordinary resources in your account, which you can inspect and adjust afterwards. Beanstalk itself adds no charge beyond what those resources cost. That combination is its signature: hand over the deployment, keep the access.

Contrast it with the neighbours a question will offer. EC2 hands you servers and nothing else. CloudFormation builds precisely what you described, which means you first have to know what the application needs. AWS Lambda removes server management more completely than any of them, at the price of repackaging the application as event-driven functions with no environment to look at. A stem that stresses BOTH "we just want to deploy our code" AND "we still want to see the resources" is describing Beanstalk.

Cloud, hybrid and on premises

Three deployment models, and the exam separates them by where the pieces of one workload run. Everything in AWS is a cloud deployment. Everything on hardware you own, virtualised or not, is on premises or a private cloud. Both at once, integrated, is hybrid — normally chosen for one of three reasons: latency to something physical, a rule about where data may sit, or an investment that is not worth moving yet. The discriminator worth memorising is that hybrid is about WHERE the workload runs and not about how many Regions you use: an application spread across three Regions is still entirely in the cloud.

A hybrid deployment needs a path between the two halves, and there are two. An AWS Site-to-Site VPN builds an encrypted tunnel over the public internet and can be working within the hour. AWS Direct Connect is a dedicated physical circuit into AWS, which costs more and takes weeks to provision but does not vary with internet conditions. Nothing about having an on-premises component restricts what the AWS side may use, and AWS bills only AWS resources — the exception being AWS Outposts, where AWS-owned racks sit in your building and are billed by AWS.