Deployment & Operating Methods — CLF-C02 Study Guide

The four ways to interact with AWS

Click a button in the console, run a CLI command, or call an SDK from your code, and AWS does the exact same thing: every one of those is the same API call wearing a different coat. That single fact is the sharpest rule on this page about how you drive AWS services like EC2 and S3, and the page also covers where a workload runs.

One model ties every interface together. Every action on AWS (launching a server, creating a bucket, granting a permission) is a call to a service API (the HTTPS request a program sends to make something happen). Those APIs are the single control plane: the one system that carries out every change. The interfaces below form an abstraction ladder on that control plane: each is a different client issuing the same API calls, differing only in workflow, never in what they can do.

1. AWS Management Console: a web-based graphical interface at console.aws.amazon.com^[1]. You point and click to manage resources; friendliest for beginners, one-time setup, and visually exploring a service or dashboard. Its weakness: clicks are not saved as a reusable artifact, so reproducing the same setup later is manual and error-prone.

2. AWS Command Line Interface (CLI): a single downloadable tool that controls AWS services from your terminal. AWS states the CLI "provides direct access to the public APIs of AWS services" and implements functionality "equivalent to that provided by the browser-based AWS Management Console." Because commands save in shell scripts, the CLI makes tasks repeatable and automatable (What is the AWS CLI?^[2]).

3. AWS SDKs (Software Development Kits): language-specific libraries (Python, JavaScript, Java, .NET, Go, and more) that call AWS services from inside your own application code (AWS developer tools^[3]). A program uploading a file to Amazon S3 as part of its logic uses an SDK.

4. The service APIs themselves: the lowest rung and the shared foundation above. The other three are clients that ultimately invoke these HTTPS APIs; you rarely call the raw API by hand.

A key exam guarantee follows from this one-control-plane model: all IaaS administration functions in the Console are also available through the API and CLI, at launch, or within 180 days for new features (AWS CLI overview^[2]).

The provisioning abstraction ladder: Console, CLI, and SDKs are three clients issuing the same calls to one control plane (the service APIs) differing in workflow, not in capability.

One-time tasks vs. repeatable automation (and IaC)

This section adds one more rung above the clients above, the answer when a scenario stresses repeatable provisioning rather than a single action. The exam tests manual, one-time provisioning versus automated, repeatable provisioning. Read the figure below as a ladder of repeatability: each rung up captures more of your work as a reusable artifact.

One-time / manual: clicking through the Console (the point-and-click client above) to set up one resource, no record to replay, and humans make inconsistent choices, so environments drift apart over time.
Repeatable / automated: capturing the steps so the same result is produced every time. The CLI and SDKs make actions scriptable. To provision a whole collection of related resources consistently, you climb to the top rung: Infrastructure as Code (IaC), defining resources in a template file rather than creating them by hand.

AWS CloudFormation is AWS's native IaC service. You describe the resources in a declarative template (a JSON or YAML file) and CloudFormation provisions them together as a stack (one collection of resources managed as a single unit), "in an orderly and predictable fashion," with automatic rollback if something fails and the ability to manage resources "across accounts and regions" (AWS CloudFormation FAQs^[4]). Because the template is a text file, you can put it under version control and review changes like source code.

Why IaC matters for deployment decisions:

Repeatability: deploy identical dev, test, and prod environments from one template.
Consistency: eliminates configuration drift from manual clicks.
Speed and automation: spin up or tear down a full environment in one operation.
Auditability: the template is the documentation of what was deployed.

There is no additional charge for CloudFormation itself: you pay only for the AWS resources it creates, "just as if you had created them manually" (AWS CloudFormation FAQs^[4]). For CLF-C02 you only need to recognize that IaC/CloudFormation is the right answer for repeatable provisioning, never to write template syntax.

The repeatability ladder: manual Console clicks (drift) → scriptable CLI/SDKs → Infrastructure as Code with CloudFormation, each rung capturing more work as a reusable artifact.

Deployment models: cloud, hybrid, and on-premises

Beyond how you provision, the exam asks where a workload runs. Picture the three deployment models as one spectrum of how much sits in AWS: at one end the whole workload lives in AWS, at the other it stays entirely in your own building, and hybrid is the deliberate middle.

Cloud ("all-in"): the everything-in-AWS end: the workload runs entirely on AWS, giving elasticity, global reach, pay-as-you-go pricing, and no hardware to own. This is the default target for new (cloud-native) applications.

Hybrid: the middle of the spectrum: some components run on AWS and some stay in your own data center, connected together. Common reasons:

A phased migration, moving workloads gradually rather than all at once.
Low-latency processing that must happen physically close to users, factories, or equipment.
Data-residency or regulatory rules that require certain data to stay on-premises.
Protecting an existing on-premises investment while extending into the cloud.

AWS supports hybrid with services such as AWS Outposts, which places AWS-designed hardware in your own facility and lets you use "the same AWS Management Console, APIs, and CLI" there as in an AWS Region (AWS Outposts FAQs^[6]).

On-premises (private cloud): the nothing-in-AWS end: infrastructure runs in your own data center, with no public-cloud component. Chosen when full local control or strict isolation is mandatory.

To answer, place the scenario's constraint on the spectrum: latency-sensitive local processing or data must stay in our building pulls toward hybrid (or on-premises); scale globally and stop managing hardware pulls toward the cloud end.

The deployment-model spectrum by how much runs in AWS: Cloud (all-in) at one end, On-premises (none) at the other, Hybrid the middle, chosen by latency, data residency, or existing investment.

Exam-pattern recognition: picking the right method

CLF-C02 deployment questions usually describe a goal and ask which interface or model fits. Map the keyword in the stem to the answer, using the models built above.

Interface / provisioning keywords:

"point-and-click," "web interface," "visually," "new to AWS," "one-time" → AWS Management Console.
"script," "from the command line," "terminal," "automate a quick task" → AWS CLI.
"from within my application," "in my Python/Java/JavaScript code," "programmatically in code" → AWS SDK.
"repeatable," "consistent across environments," "infrastructure as code," "template," "provision a whole stack the same way" → AWS CloudFormation (IaC).

Deployment-model keywords:

"entirely on AWS," "cloud-native," "no data center" → cloud / all-in.
"connect on-premises to AWS," "phased migration," "keep some workloads local," "low latency on-site" → hybrid (e.g., AWS Outposts).
"must remain in our own data center," "fully on-premises" → on-premises.

Why common distractors are wrong (each ties back to a rule built above):

The Console is not the answer for repeatable or consistent deployment: by the one-time-vs-repeatable rule above, manual clicks drift, which is what IaC fixes.
The CLI/SDK are not best for managing an entire resource stack with rollback and version control; that is CloudFormation's job from the IaC rung above.
A pure cloud model is wrong when the scenario states data must physically stay on-premises: on the spectrum above, that constraint pulls toward hybrid or on-premises.
CloudFormation is not a billing or cost tool, and (as noted above) it carries no service fee of its own (AWS CloudFormation FAQs^[4]); you pay only for the resources it creates.

Ways to provision and operate AWS

Method	Interface	Repeatable?	Best for
Management Console	Web GUI in a browser	No (manual clicks)	One-time setup, learning, dashboards
AWS CLI	Commands in a shell	Yes (scriptable)	Scripting and quick automation
AWS SDKs	Language libraries in app code	Yes (in code)	Embedding AWS calls in applications
AWS CloudFormation	Declarative JSON/YAML templates	Yes (idempotent stacks)	Consistent, version-controlled IaC

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Console, CLI, SDKs, and APIs all hit one control plane

The AWS Management Console, AWS CLI, and AWS SDKs are all clients that ultimately call the same public service APIs: the API is the single control plane beneath all of them. Picking a method is a workflow choice (clicking vs. scripting vs. embedding in app code), not a capability choice, since none of them can do anything the API can't.

Trap Assuming the CLI or SDK can perform some action the Console can't (or vice versa), when all four are just clients of the same underlying API and share its capabilities.

Anything you can do in the Console is also in the CLI/API

AWS commits that all IaaS administration, management, and access functions available in the Management Console are also available through the API and AWS CLI; new IaaS features reach full Console parity through the API and CLI at launch or within 180 days of launch. So "the Console can do it but the CLI can't" is essentially never the right reasoning for an IaaS task.

Trap Treating an IaaS task as Console-only because it looks click-driven, when AWS guarantees the same functions through the API and CLI within 180 days of a feature's launch.

The Management Console is the browser-based GUI

The AWS Management Console is a browser-based, point-and-click interface, best for one-time setup, learning, visual exploration, and dashboards. Its weakness is repeatability: clicks leave no reusable artifact, so the same setup done twice can drift apart.

3 questions test this

Reach for the CLI to script and automate from a terminal

The AWS CLI is a single command-line tool that gives direct access to the public service APIs from your shell, with commands roughly equivalent to the Console's actions. That makes tasks scriptable, repeatable, and automatable: the answer when a scenario says "automate," "from a script," or "from the terminal."

Trap Choosing the SDK for a shell-driven automation task, when 'from a script' or 'from the terminal' points at the CLI rather than embedding calls in application code.

3 questions test this

Use SDKs to call AWS from inside application code

AWS SDKs are language-specific libraries (Python, JavaScript, Java, .NET, Go, and more) for calling AWS services programmatically from within your own application. The cue is "from my application" or a named language: an app integrating S3 or DynamoDB uses the SDK, not the CLI.

Trap Reaching for the CLI when the scenario says 'from my application' or names a programming language, where calling AWS in-process is the SDK's job, not the shell's.

4 questions test this

Every AWS action is ultimately an API call

Service APIs are the common foundation beneath the Console, CLI, and SDKs: each of those is just a different front end onto the same HTTPS API calls. Understanding this explains why a permission, a quota, or an action behaves identically no matter which interface you used.

One-off clicks are fine; repeatability needs scripting or IaC

Manual Console clicks suit a one-time task, but repeating them by hand invites configuration drift and inconsistency between environments. When a scenario stresses consistent, repeatable provisioning across accounts or Regions, the answer shifts to scripting (CLI/SDK) or Infrastructure as Code (CloudFormation).

Trap Reaching for the Console to stand up identical environments repeatedly, where manual clicks guarantee drift instead of a reproducible result.

2 questions test this

CloudFormation is AWS-native Infrastructure as Code

AWS CloudFormation is AWS's Infrastructure as Code service: you describe resources in a declarative JSON or YAML template, and it provisions and configures the whole collection together as a single unit called a stack, handling dependency ordering for you. It's the AWS-native answer whenever a scenario wants resources modeled as code and deployed predictably.

9 questions test this

IaC gives repeatable, version-controlled, reviewable environments

Infrastructure as Code defines resources in a text template, so environments can be reproduced identically, committed to version control, peer-reviewed, and torn down on demand: the same revision discipline developers apply to source code. It's the right answer when a scenario stresses consistency, repeatability, or change tracking.

10 questions test this

CloudFormation itself is free; you pay only for what it builds

There is no additional charge for AWS CloudFormation when it provisions AWS resource types (the AWS::* namespace): you pay only for the underlying resources it creates, exactly as if you'd made them by hand. (Third-party/registry resource types and Hooks are the narrow exception, billed per handler operation.)

Trap Assuming CloudFormation adds a service fee on top of the resources it provisions, when AWS resource types carry no extra CloudFormation charge.

CloudFormation auto-rolls-back on failure and spans accounts/Regions

AWS CloudFormation manages a stack as one unit: if a create or update fails, it automatically rolls the resources back to their previous working state rather than leaving a half-built stack. With StackSets, a single template can also deploy and manage resources across many accounts and Regions at once.

1 question tests this

A company needs to deploy the same standardized set of resources into several AWS accounts and multiple Regions in a consistent, repeatable…

Workloads run cloud, hybrid, or on-premises

A deployment model is chosen by where the workload runs: cloud (fully in AWS), hybrid (cloud resources connected to existing on-premises infrastructure), or on-premises (your own data center, sometimes called private cloud). Match it to latency, data-residency, and migration constraints rather than treating cloud as automatically correct.

1 question tests this

An insurance company will keep its core mainframe system running in its own data center while building all new customer-facing applications…

A cloud deployment runs the whole application in AWS

A cloud (all-in) deployment runs every part of the application in AWS, whether built there natively or migrated in, giving elasticity, global reach, and pay-as-you-go pricing with no hardware to own. It's the default for cloud-native apps with no on-premises tie.

1 question tests this

A newly launched digital bank owns no physical servers or data center facilities and runs every workload on AWS managed services. Which…

Hybrid connects on-premises infrastructure to AWS

A hybrid deployment connects existing on-premises infrastructure with cloud resources, extending the data center into AWS rather than replacing it. The usual drivers are phased migration, low-latency local processing, data-residency rules, and protecting prior on-premises investment.

4 questions test this

Outposts extends AWS hardware and APIs into your facility

AWS Outposts is a fully managed service that places AWS-designed hardware in your own data center and runs it using the same APIs, tools, and management as an AWS Region: AWS operates it as an extension of a Region. It's the go-to for a consistent hybrid experience when low-latency or local-data needs require AWS infrastructure on-site.

Trap Picking a plain Site-to-Site VPN or Direct Connect link when the requirement is actually AWS compute and storage physically on-premises, which only Outposts provides.

3 questions test this

An on-premises deployment keeps everything in your data center

An on-premises (private cloud) deployment runs entirely in your own data center using virtualization and resource-management tools, with no public-cloud component, forgoing most cloud benefits in exchange for dedicated, fully local resources. It's chosen when strict isolation or full physical control is mandatory.

Let keywords steer you to the right interface

Map the scenario's wording to the interface: "point-and-click / new to AWS / visual" → Console; "script / terminal / automate" → CLI; "from my application code / a named language" → SDK; "repeatable / consistent / template / Infrastructure as Code" → CloudFormation. The keyword is usually the whole signal.

8 questions test this

Drift detection, change sets, and stack delete control a stack

CloudFormation gives three core stack controls: drift detection flags resources whose live configuration no longer matches the template (e.g., someone edited them in the console); change sets preview exactly which resources an update will add, modify, or delete before you execute it; and deleting the stack removes all its provisioned resources together in one coordinated operation.

Trap Confusing change sets with drift detection, when change sets preview an update before you run it and drift detection reports out-of-band edits after they happen.

4 questions test this

Also tested in

AZ-900 Microsoft Azure Fundamentals

The four ways to interact with AWS

One-time tasks vs. repeatable automation (and IaC)

Deployment models: cloud, hybrid, and on-premises

Exam-pattern recognition: picking the right method

Ways to provision and operate AWS

Decision tree

Cheat sheet

Also tested in

References