Deploying and Operating in AWS: Console, CLI, SDKs, IaC, and Connectivity

Before comparing access methods, understand what they all have in common: underneath every one of them sits the AWS application programming interface (API). AWS exposes each service — compute, storage, databases, everything — as a set of API operations delivered over HTTPS. When you click "Launch instance" in the web console, the console makes an API call on your behalf. When you type a command in the AWS CLI, the CLI translates it into the same API call. When your application uses an SDK, the SDK wraps that same API in the syntax of your programming language. There is one interface to AWS; the access methods are simply different ways for humans and software to reach it.

This single fact explains most of what the exam asks in this task. Because everything is an API call, everything can be automated: any action a person performs manually can be reproduced exactly by a script, an application, or a template. It also means every action is authenticated and signed — API requests carry credentials, which is why programmatic access requires access keys (or, better, temporary credentials from an IAM role) while console access uses a username, password, and ideally multi-factor authentication (MFA).

For the exam, keep the mental model simple: the API is the foundation; the Console, CLI, SDKs, and IaC tools are layers on top of it. When a question says an application needs to "call AWS services directly" or interact with AWS "programmatically from code," it is pointing you below the console layer — toward the SDKs and APIs. When a question describes a person exploring or performing a visual, occasional task, it is pointing at the console. The rest of this lesson turns that instinct into a precise decision framework.

The AWS Management Console is the web-based graphical interface at the center of most people's first AWS experience. You sign in through a browser with an identity — root user or, far better, an IAM user or federated identity — protected by a password and MFA. From there you navigate services visually, fill in forms, and see dashboards, graphs, and wizards that guide you through configuration choices. A mobile version, the AWS Console Mobile Application, lets you monitor resources and respond to alarms from a phone.

The console's strengths are discoverability and low friction. You do not need to memorize command syntax or write code; wizards surface the available options and validate input as you go. That makes the console the natural choice for learning a new service, exploring what exists in an account, one-time or infrequent tasks, and visual monitoring — reading a billing dashboard, inspecting a resource's configuration, or walking through a setup wizard once.

Its weakness is the flip side of the same coin: console work is manual. A human clicking through forms is slow, hard to reproduce exactly, and prone to typos and skipped steps. If you configure ten environments through the console, you will get ten slightly different environments. Nothing about a console session is version-controlled or reviewable — there is no artifact you can diff, test, or roll back. That is why the console is the wrong answer whenever a scenario mentions repetition, automation, consistency, or scale.

Exam trigger: phrases like "a new administrator wants to explore," "perform a one-time configuration," "view a dashboard," or "graphical interface" point to the Management Console. Phrases like "repeatable," "automate," "script," or "from application code" point away from it.

The AWS Command Line Interface (AWS CLI) is a tool you install on your workstation or server that lets you control AWS services by typing commands in a terminal — for example, a single command to list buckets, launch instances, or copy files to storage. Because commands are text, they can be chained into shell scripts: a sequence of steps a human would click through in the console becomes a script that runs the same way every time, on demand or on a schedule. The CLI is the tool of choice for administrators and DevOps engineers automating operational tasks — batch operations, scheduled jobs, quick queries, and repeatable admin work that does not justify a full application.

The AWS Software Development Kits (SDKs) serve a different audience: developers writing applications. An SDK is a library for a specific programming language — Python, JavaScript, Java, C#, Go, and others — that exposes AWS API operations as ordinary functions in your code. Instead of hand-crafting signed HTTPS requests, your application calls an SDK method, and the SDK handles request signing, retries, and response parsing. Use an SDK whenever software, not a person, needs to interact with AWS as part of its normal operation — an app that stores user uploads in object storage, reads from a database, or publishes messages to a queue.

The distinction the exam draws between them is about who is acting. A person at a terminal scripting operations: CLI. An application integrating AWS calls into its own logic: SDK. Both are programmatic, both authenticate with credentials rather than a browser sign-in, and both ultimately issue the same API calls. Direct use of the raw HTTPS APIs — without CLI or SDK — is possible but rare; you would only do it in an environment with no SDK support.

AWS CloudShell sits between the two worlds. It is a browser-based shell you open from the Management Console, with the AWS CLI already installed and your console sign-in used as its credentials, so there is nothing to install on your own machine. Despite running in the browser, CloudShell is a command line, not a visual interface: you type CLI commands and scripts in it, and it has no wizards or dashboards. Think of it as "the CLI without a local install," not as an alternative to the console.

Access methods at a glance

Infrastructure as code (IaC) means describing your infrastructure — networks, servers, databases, permissions — in machine-readable definition files instead of creating it by hand. On AWS, the flagship IaC service is AWS CloudFormation. You write a template in JSON or YAML that declares every resource you want and how the pieces relate; CloudFormation reads the template and provisions everything as a single managed unit called a stack. Deploy the same template again — in another account, another Region, or for another team — and you get an identical environment.

The benefits are exactly the words the exam likes to use. Repeatable: one template can create the same environment any number of times. Consistent: no configuration drift between environments, because they all come from the same definition. Version-controllable: templates are text files, so they live in a source-control system where changes are reviewed, diffed, and rolled back like application code. Less error-prone: a template eliminates the missed step or mistyped value that creeps into manual work. CloudFormation also manages the full lifecycle — update the template and it changes the stack to match; delete the stack and it cleans up the resources it created.

Contrast this with the CLI. A CLI script is imperative: it lists the steps to run, one after another. A CloudFormation template is declarative: it describes the desired end state, and the service figures out the steps, ordering, and dependencies. For provisioning entire environments, declarative wins — you cannot half-run a template into an inconsistent state the way a failed script can.

Templates vs Amazon Machine Images

A CloudFormation template and an Amazon Machine Image (AMI) both help you "copy" something, but they copy different things. An AMI is a saved image of one EC2 instance: its operating system, installed software and configuration, used to launch more instances that start out the same. It does not contain the resources around the instance — the VPC and subnets, security groups, databases, load balancers or IAM roles. Launching servers from AMIs therefore reproduces servers, not an environment; everything else would still have to be built by hand. A template declares the whole environment, and it can itself reference an AMI for the instances it launches. Use an AMI to standardize what runs on a server; use a template to recreate the full set of resources consistently.

What CloudFormation does not do on its own

Knowing the limits of IaC is as important as knowing its benefits, because the limits are where wrong answers come from:

• Drift detection reports; it does not revert. If someone changes a stack's resource by hand, CloudFormation drift detection can show what differs from the template, but it does not undo the change. You fix drift by updating the resource or the template and deploying again. IaC prevents drift only when people make changes through the template rather than by hand.
• A template does not scale resources with demand. CloudFormation creates whatever the template declares. Adding and removing capacity as load changes is the job of a service such as Amazon EC2 Auto Scaling, which a template can create and configure, but the scaling itself is done by Auto Scaling, not by CloudFormation.
• A stack lives in one Region. A stack exists only in the Region where you deploy it; nothing is copied to other Regions automatically. To get the same environment elsewhere, you deploy the template again in each Region, or use CloudFormation StackSets, which create, update, and delete stacks across multiple accounts and Regions from one operation.

One line on a related tool: the AWS Cloud Development Kit (CDK) lets developers define infrastructure in familiar programming languages such as Python or TypeScript, and it synthesizes CloudFormation templates under the hood. For CLF-C02, CloudFormation is the IaC answer; know CDK exists as a code-first path to the same result.

Task 3.1 explicitly tests a judgment skill: given a requirement, decide whether a one-time manual operation is acceptable or a repeatable automated process is required. The rule is simple. If a task will be performed once — or so rarely that automating it costs more than it saves — doing it in the console is fine. Enabling a setting on a single account, exploring a service to evaluate it, or checking a chart during an incident are legitimately manual moments. There is no shame in the console; it exists for exactly this.

The moment a task will be repeated, the calculus flips. Repetition is where manual work fails: each repetition is an opportunity for a typo, a skipped step, or a different choice than last time, and the cost of clicking through the process is paid again on every run. Repeated tasks should be captured as code — a CLI script for operational sequences, an SDK-based tool when application logic is involved, or a CloudFormation template when the "task" is provisioning an environment. Automated processes run the same way every time, scale without added human effort, can be scheduled, and leave an auditable, reviewable artifact.

The exam's favorite version of this question is environment provisioning. If a company needs to "create identical development, test, and production environments," or "deploy the same stack in multiple Regions," or "recreate infrastructure quickly and without manual errors," the answer is infrastructure as code — CloudFormation — not a well-documented console procedure and not even a CLI script. A documented manual runbook is still manual; only code guarantees consistency. Conversely, if the scenario stresses that something happens once, by a person, with no need to reproduce it, the console is not just acceptable but the most efficient answer.

Deployment models describe where your workloads run, and there are three: cloud, hybrid and on-premises. Multi-cloud, which appears in the table below for contrast, is not a fourth model — it describes using more than one provider.

A cloud (cloud-native) deployment runs entirely in the cloud. All parts of the application live on AWS infrastructure — whether built new in the cloud or fully migrated from elsewhere. This model gives you the full cloud value proposition: pay-as-you-go pricing, elastic capacity, no data-center hardware to buy or maintain, and global reach on demand. When a scenario describes a startup building a new application with no existing infrastructure, or a company that has "migrated all workloads to AWS," that is a cloud deployment.

An on-premises deployment — often called a private cloud when cloud-style virtualization and self-service tooling are used — runs entirely in the organization's own data center on hardware it owns and operates. Using virtualization and resource-management tools on your own servers can improve utilization, but it does not deliver the economics of the public cloud: you still buy capacity up front, maintain it, and carry the fixed costs. Organizations choose this model for strict regulatory or data-control requirements, or simply because that is where their systems already are.

A hybrid deployment connects cloud-based resources to existing on-premises infrastructure so the two operate together as one environment. This is the model the exam probes hardest, so learn its triggers: legacy applications that must stay on-premises (too costly or risky to move, or dependent on local hardware); data residency, sovereignty, or compliance rules that require certain data to remain in a specific facility; and gradual migration, where workloads move to AWS in phases and must keep talking to what has not moved yet. A classic hybrid pattern keeps a legacy database in the corporate data center while new web tiers run on AWS, connected by a private link. Any scenario with the words "connect existing on-premises infrastructure to AWS" or "extend the data center to the cloud" is describing hybrid.

AWS Outposts is a hybrid deployment in a box. Outposts racks are AWS-designed hardware that AWS installs and manages in your own facility; each Outpost is connected to, and managed through, a parent AWS Region. A company that runs low-latency or data-local workloads on Outposts in its factory while running other workloads in the Region is running a hybrid deployment: AWS infrastructure and services on premises, working together with the AWS Region. It is not "cloud only," because part of the workload runs in the customer's building, and it is not traditional on-premises, because the hardware is AWS-owned and AWS-managed. (Outposts itself is covered with the rest of the global infrastructure in the Task 3.2 lesson.)

Multi-cloud is a different idea that appears alongside these models as a distractor: it means using services from more than one cloud provider, for example AWS together with another public cloud. Multi-cloud is about how many providers you use, not about where your own data center fits in. A company that has moved everything to AWS is cloud, not multi-cloud; a company that connects its data center to AWS is hybrid, not multi-cloud.

Comparing the three models

• Cloud: everything on AWS — maximum elasticity and pay-as-you-go; no hardware ownership; the default for new applications.
• Hybrid: AWS plus on-premises, connected — chosen for legacy systems, compliance and data-residency constraints, or phased migration.
• On-premises (private cloud): everything in your own data center — maximum control over hardware and data location, at the cost of upfront capital, capacity planning, and maintenance.

Once part of your environment is outside AWS — a hybrid deployment, a remote office, or simply users — you need a way to reach AWS. The official task names three options: the public internet, AWS VPN and AWS Direct Connect.

The public internet is the default. Every AWS API call and public endpoint is reachable over the internet, protected in transit by TLS encryption. It requires no setup and no extra cost beyond standard data transfer, which makes it right for general access, public-facing applications, and getting started. Its drawbacks: performance is variable, because your traffic crosses networks you do not control, and while the traffic is encrypted, it still traverses shared public infrastructure — which some security or compliance postures will not accept for sensitive internal traffic.

AWS VPN has two members, and they connect different things. An AWS Site-to-Site VPN creates an encrypted tunnel between your on-premises network and your AWS environment, running over the public internet. It is quick to set up — typically hours, since it is configuration on both ends rather than physical work — and inexpensive relative to a dedicated line. The traffic is encrypted in IPsec tunnels between your customer gateway device and the AWS VPN endpoints, giving you a private, secure channel over the internet. But because the tunnel still rides the public internet, bandwidth and latency remain variable; a VPN buys you encryption and network integration, not consistent performance.

AWS Client VPN is the other half of AWS VPN: a managed VPN service that connects individual users' devices (laptops of remote employees, for example) to AWS, using VPN client software on each device. It does not link a data center or office network to AWS. The test is simply what sits at the other end: a whole network (data center, branch office) → Site-to-Site VPN; individual people on their own devices → Client VPN.

AWS Direct Connect is a dedicated, private physical network connection between your data center (or a partner colocation facility) and AWS. Your traffic does not traverse the public internet at all. That delivers consistent, predictable bandwidth and latency at high capacities, and a level of network privacy that satisfies strict compliance requirements. The trade-offs are cost and time: a physical circuit must be provisioned, which takes weeks or longer and carries meaningfully higher cost than a VPN. One nuance worth remembering: Direct Connect provides a private path, but it is not encrypted by default. Organizations that need both privacy and encryption run an AWS Site-to-Site VPN over the Direct Connect connection (some dedicated connections at selected locations can also use MACsec link-layer encryption, which you must set up). Adding a second Direct Connect connection gives you more capacity and resilience, but no encryption: isolation and capacity are not encryption, and two unencrypted links are still unencrypted. Client VPN does not apply here either, because it connects users' devices, not the data center network.

Choosing a connection: the decision list

• Speed of setup: public internet — immediate; Site-to-Site VPN — hours to days; Direct Connect — weeks or months (physical provisioning).
• Cost: public internet — lowest; VPN — low (service charges over existing internet); Direct Connect — highest (dedicated circuit).
• Performance consistency: public internet and VPN — variable, at the mercy of internet conditions; Direct Connect — consistent, predictable bandwidth and latency.
• Privacy of path: public internet — shared path, encrypted by TLS; VPN — encrypted tunnel over a shared path; Direct Connect — private dedicated path that never touches the public internet.
• Typical exam match: "quickly establish a secure, encrypted connection" between a network and AWS → Site-to-Site VPN; "remote employees connect from their laptops" → Client VPN; "consistent network performance" or "traffic must not traverse the public internet" → Direct Connect; "lowest cost, no special requirements" → public internet.

Pull the whole task together with a realistic scenario. A regional insurance company is moving to AWS. Its claims database must remain in its own data center for two more years because a regulator requires the data to stay in a certified local facility. Meanwhile, the company is building a new customer portal on AWS, and the platform team must stand up identical development, staging, and production environments for it. The portal application will store documents in AWS object storage. Operations staff want a nightly job that produces a resource report, and a newly hired cloud administrator wants to look around the account. Finally, the portal on AWS must query the on-premises claims database with reliable, consistent latency, and the connection must be live before launch in three weeks.

Work through it decision by decision. The overall deployment model is hybrid: AWS resources (the portal) connected to on-premises infrastructure (the claims database), triggered here by a data-residency requirement — one of the classic hybrid drivers. The three identical environments are a repeatable provisioning problem, so the answer is IaC: a CloudFormation template deployed three times, not three console sessions. The portal storing documents from its own code is an SDK use case — an application calling AWS programmatically. The nightly report is a scheduled, scripted operational task: AWS CLI in a script. The new administrator exploring the account is a human, visual, low-stakes activity: the Management Console.

The connectivity question has a twist worth noticing. "Consistent latency" points to Direct Connect — but "live in three weeks" makes a dedicated circuit unrealistic, since physical provisioning takes weeks to months. The pragmatic answer is a Site-to-Site VPN now (encrypted, up in days) with Direct Connect ordered for the long term. Real exam questions usually isolate one constraint at a time — "needs consistent bandwidth" or "needs a connection quickly" — but reading both constraints in one scenario trains you to spot which requirement the question is actually testing.