Deployment & Operation Methods

Deploying and operating in AWS means choosing how you provision, configure, update, and automate cloud resources across the AWS global footprint. The CLF-C02 exam (Task Statement 3.1) tests whether you can distinguish the three AWS deployment access methods (Management Console, AWS CLI, AWS SDK), explain Infrastructure as Code with AWS CloudFormation and AWS CDK, select the right deployment model (cloud, hybrid, on-premises), and identify managed deployment platforms such as AWS Elastic Beanstalk alongside operational services like AWS Systems Manager. This guide teaches the complete set of AWS deployment methods in the depth required for CLF-C02 while staying within Domain 3 scope.

What Are AWS Deployment & Operation Methods?

AWS deployment methods are the tools, interfaces, and patterns you use to create and manage AWS resources. AWS operation methods are the tools you use to run, monitor, patch, and update those resources after they are deployed. The CLF-C02 exam treats deployment and operation as a single Task Statement 3.1 because real-world AWS work always combines the two: you deploy using AWS CloudFormation, then you operate using AWS Systems Manager; you deploy using the AWS CLI, then you script ongoing operations using the AWS SDK; you deploy to a hybrid topology, then you operate that topology through AWS Direct Connect and AWS VPN.

At the highest level, the CLF-C02 exam expects you to know three answers to the question "How do I talk to AWS?":

1. AWS Management Console — a browser-based graphical user interface for humans.
2. AWS CLI — a command-line tool for scripts, terminals, and automation pipelines.
3. AWS SDK — software libraries that let applications make AWS API calls from languages like Python, JavaScript, Java, Go, .NET, Ruby, PHP, and C++.

You should also know three answers to the question "Where do I run workloads?":

1. Cloud (all-in) — every workload lives in AWS Regions.
2. Hybrid — some workloads run on-premises and connect to AWS through AWS Direct Connect or AWS Site-to-Site VPN, or run on AWS Outposts hardware installed at your data center.
3. On-premises (with cloud tools) — traditional data centers that use AWS-compatible tooling such as AWS CDK or AWS CloudFormation to drive consistent configuration.

These two axes — access method and deployment model — combine with Infrastructure as Code (AWS CloudFormation, AWS CDK) and managed deployment platforms (AWS Elastic Beanstalk) to give you the full CLF-C02 picture of AWS deployment methods.

Core Operating Principles — Provisioning, Operating, and Automating in AWS

Every AWS deployment method eventually lands at the same destination: the AWS service API. The AWS Management Console, AWS CLI, and AWS SDK are three different doors into the same building. Understanding this single principle unlocks most of CLF-C02 Task 3.1.

When you click "Launch Instance" in the AWS Management Console, the console makes an HTTPS call to the EC2 RunInstances API. When you type aws ec2 run-instances in the AWS CLI, the CLI makes the same HTTPS call. When Python code calls boto3.client('ec2').run_instances(...) using the AWS SDK, it also makes the same HTTPS call. The three AWS deployment methods differ only in ergonomics:

• AWS Management Console: best for first-time exploration, one-off manual tasks, and visual inspection of resources.
• AWS CLI: best for scripting, automation, shell pipelines, CI/CD jobs, and repeatable tasks across accounts.
• AWS SDK: best for embedding AWS behavior inside applications so your product code can programmatically create, read, update, and delete AWS resources.

On top of this API foundation, AWS adds higher-order deployment methods:

• AWS CloudFormation turns a declarative template into a stack of resources.
• AWS CDK generates AWS CloudFormation templates from regular programming languages.
• AWS Elastic Beanstalk takes application code and deploys the surrounding infrastructure for you.
• AWS Systems Manager provides the operational layer: patching, run commands, parameter storage, session management.

Every CLF-C02 deployment and operation question is a choice between these layers.

Why AWS Exposes Multiple Deployment Methods

AWS exposes multiple AWS deployment methods because different workflows require different levels of abstraction. A solo developer exploring Amazon S3 for the first time needs the AWS Management Console. A DevOps engineer deploying 200 microservices across 12 AWS Regions needs AWS CloudFormation. A mobile team building an app with S3-backed photo uploads needs the AWS SDK for Swift or Kotlin. By offering the AWS Management Console, AWS CLI, AWS SDK, AWS CloudFormation, and AWS CDK as complementary (not competing) options, AWS covers the entire spectrum of deployment needs.

Ways to Access AWS: Management Console, CLI, SDKs, and APIs

Every CLF-C02 candidate must fluently distinguish the three AWS deployment methods that serve as primary access points.

AWS Management Console (GUI)

The AWS Management Console is the web browser GUI at console.aws.amazon.com. It is the entry point most people first experience when learning AWS.

Strengths of the AWS Management Console:

• Zero installation — works in any browser.
• Visual discovery — you can see all AWS services and navigate by category.
• Guided wizards — services like Amazon RDS, AWS Elastic Beanstalk, and Amazon VPC have create-resource wizards that suggest sensible defaults.
• Cost and billing dashboards — AWS Billing and Cost Management is best viewed in the AWS Management Console.

Weaknesses of the AWS Management Console:

• Not automatable — you cannot schedule a cron job to "click a button."
• Not repeatable — two humans clicking the same wizard may make subtly different choices, leading to drift.
• Slow for bulk operations — creating 50 S3 buckets one-at-a-time through the console is painful.
• No version control — there is no commit history of console clicks.

AWS CLI

The AWS CLI is a command-line tool installed locally that issues AWS API calls from a shell. It is a foundational AWS deployment method for DevOps, SRE, and CI/CD pipelines.

AWS CLI command anatomy: aws <service> <operation> --<parameter> <value>. For example, aws s3 cp localfile.txt s3://my-bucket/ uploads a file; aws ec2 describe-instances --region us-east-1 lists EC2 instances.

Strengths of the AWS CLI:

• Scriptable in bash, zsh, PowerShell, or any shell.
• Consistent across all AWS services — once you know the pattern, you know every service.
• Installable on Linux, macOS, Windows, AWS CloudShell, Amazon EC2 instances, and AWS Systems Manager managed nodes.
• Fast for batch operations — you can loop over 1000 resources in a single script.

Weaknesses of the AWS CLI:

• Steeper learning curve than the AWS Management Console.
• Requires configured credentials (access keys, IAM Roles, AWS SSO profiles).

AWS SDK

The AWS SDK is a set of language-specific libraries that expose AWS APIs as native function calls. AWS provides official SDKs for Python (Boto3), JavaScript/TypeScript, Java, .NET, Go, Ruby, PHP, C++, Swift, Kotlin, and Rust. The AWS SDK is the correct AWS deployment method when AWS functionality must be embedded inside application code.

Strengths of the AWS SDK:

• Native language constructs — idiomatic objects, async/await support, typed parameters.
• Integrated credential resolution — automatically uses IAM Roles on EC2, Lambda execution roles, or local profiles.
• Built-in retry, timeout, and paginator helpers.
• Works anywhere the language runs — mobile apps, backend services, AWS Lambda functions, Amazon ECS containers.

Weaknesses of the AWS SDK:

• Requires coding skills.
• Requires dependency management in the application.

Programmatic Access: AWS CLI and AWS SDK in Depth

Programmatic access is the CLF-C02 umbrella term for any AWS deployment method that is not a human clicking. The two programmatic access AWS deployment methods you must know are the AWS CLI and the AWS SDK.

Programmatic Access via AWS CLI

Programmatic access with the AWS CLI is achieved through access keys (access key ID + secret access key) or, better, IAM Roles with short-lived credentials via AWS STS. The AWS CLI is often the fastest path when you need to automate a one-off job, feed output into shell pipes, or drive AWS Systems Manager Run Command across fleets of instances.

Common AWS CLI programmatic access patterns tested on CLF-C02:

• A DevOps engineer writes a bash script using the AWS CLI to rotate IAM access keys across accounts.
• A CI/CD pipeline uses the AWS CLI to push artifacts to Amazon S3 and trigger AWS CodeDeploy.
• An administrator uses the AWS CLI through AWS CloudShell (browser-based shell bundled with the AWS Management Console) without installing anything locally.

Programmatic Access via AWS SDK

The AWS SDK is the programmatic access path when AWS API calls must happen inside an application. The AWS SDK uses the same IAM permission model and credential resolution chain as the AWS CLI: environment variables, shared credential files, IAM Roles for EC2, or IAM Roles for service accounts.

Common AWS SDK programmatic access patterns tested on CLF-C02:

• A Python application running on Amazon EC2 uses Boto3 (AWS SDK for Python) to write records to Amazon DynamoDB. No long-term credentials are stored — the instance profile IAM Role provides short-term credentials automatically.
• A JavaScript web app uses the AWS SDK for JavaScript in the browser, paired with Amazon Cognito for identity.
• An AWS Lambda function written in Go uses the AWS SDK for Go to publish messages to Amazon SNS.

Infrastructure as Code: AWS CloudFormation, AWS CDK, AWS SAM

Infrastructure as Code (IaC) is the practice of defining cloud infrastructure in text files that can be version-controlled, peer-reviewed, and deployed repeatedly. Infrastructure as Code is the dominant AWS deployment method for production workloads because it solves the repeatability problem that manual AWS Management Console clicking creates.

AWS CloudFormation

AWS CloudFormation is the native AWS Infrastructure as Code service. You write a CloudFormation template in YAML or JSON, describe the AWS resources you want (EC2 instances, S3 buckets, IAM Roles, VPCs, and so on), and AWS CloudFormation deploys them as a single unit called a stack.

Core AWS CloudFormation concepts for CLF-C02:

• Template — YAML or JSON file describing resources, parameters, mappings, outputs, and conditions.
• Stack — the collection of AWS resources created from one template.
• Change Set — a preview of what AWS CloudFormation will change before applying updates.
• Drift Detection — AWS CloudFormation detects when resources in a stack have been modified outside the template.
• Declarative — you describe the desired end state; AWS CloudFormation figures out the order of operations.

AWS CloudFormation is declarative: you say what you want, not how to build it. This is different from an imperative script where you say "do step 1, then step 2, then step 3." Declarative Infrastructure as Code is safer because AWS CloudFormation can roll back a failed deployment, detect drift, and update stacks idempotently.

AWS CDK (Cloud Development Kit)

AWS CDK is a higher-level Infrastructure as Code framework that lets you define AWS CloudFormation stacks using familiar programming languages: TypeScript, JavaScript, Python, Java, C#, and Go. AWS CDK generates AWS CloudFormation templates under the hood and hands them to AWS CloudFormation for deployment.

Why AWS CDK exists: AWS CloudFormation YAML can become verbose for complex architectures. Developers prefer loops, conditions, and reusable classes from general-purpose languages. AWS CDK gives you those tools while keeping AWS CloudFormation as the deployment engine.

AWS SAM (Serverless Application Model)

AWS SAM is an Infrastructure as Code extension of AWS CloudFormation tailored for serverless applications. AWS SAM simplifies writing AWS Lambda, Amazon API Gateway, and Amazon DynamoDB templates. AWS SAM transforms its shorthand into full AWS CloudFormation templates at deploy time.

AWS OpsWorks

AWS OpsWorks is an AWS configuration management service that supports Chef and Puppet — two open-source configuration-management tools. AWS OpsWorks lets you apply imperative configuration recipes to Amazon EC2 instances. It is less commonly tested than AWS CloudFormation on CLF-C02 but appears as a distractor answer.

Managed Deployment Platforms: AWS Elastic Beanstalk

AWS Elastic Beanstalk is a managed deployment AWS service that takes your application code (Java, .NET, PHP, Node.js, Python, Ruby, Go, or Docker) and automatically provisions the surrounding infrastructure: Amazon EC2 instances, Elastic Load Balancers, Auto Scaling groups, and AWS CloudWatch monitoring. AWS Elastic Beanstalk is often described as "PaaS-like" because you manage your app, not the servers.

Key AWS Elastic Beanstalk properties for CLF-C02:

• You upload code, AWS Elastic Beanstalk handles deployment.
• You choose the platform (Python, Node.js, Docker, and so on) and AWS Elastic Beanstalk provisions the matching runtime.
• You retain full control over the underlying AWS resources — they appear in your AWS account and can be inspected or modified.
• There is no additional charge for AWS Elastic Beanstalk itself — you pay only for the underlying AWS resources (EC2, ELB, Auto Scaling).

AWS Elastic Beanstalk is a deployment method, not a compute service. The exam distinguishes:

• Compute services (Task 3.3): Amazon EC2, AWS Lambda, Amazon ECS, Amazon EKS, AWS Fargate.
• Deployment methods (Task 3.1): AWS CloudFormation, AWS CDK, AWS Elastic Beanstalk, AWS OpsWorks.

AWS Elastic Beanstalk uses Amazon EC2 underneath but is classified as a deployment method in CLF-C02's exam guide because its value is deployment automation, not compute primitives.

AWS Systems Manager — Operational Automation

AWS Systems Manager is the AWS operations service that sits alongside AWS deployment methods. Once resources are deployed (via AWS Management Console, AWS CLI, AWS SDK, AWS CloudFormation, or AWS Elastic Beanstalk), AWS Systems Manager handles ongoing operations: patching, command execution, parameter storage, and secure shell-like access.

Core AWS Systems Manager capabilities tested on CLF-C02:

• AWS Systems Manager Patch Manager — automates OS patching for Amazon EC2 instances and hybrid on-premises servers.
• AWS Systems Manager Run Command — executes commands across fleets of instances without SSH or RDP.
• AWS Systems Manager Parameter Store — stores configuration values and secrets (plaintext or KMS-encrypted).
• AWS Systems Manager Session Manager — provides browser-based shell access to EC2 instances without opening inbound ports or managing SSH keys.
• AWS Systems Manager State Manager — enforces a desired configuration state across managed instances.
• AWS Systems Manager Automation — runbook-style workflows for repeatable ops tasks.

AWS Systems Manager is the glue between AWS deployment methods and Day-2 operations. The CLF-C02 exam treats AWS Systems Manager as an operational AWS deployment method because it handles the "operating" half of Task 3.1.

Deployment Models: Cloud-Native, Hybrid, On-Premises

CLF-C02 defines three AWS deployment models that describe where your workloads live.

All-In Cloud (Cloud-Native) Deployment

All-in cloud means 100% of the application stack runs in AWS Regions. No servers live in a customer data center. This is the default AWS deployment model for startups, greenfield projects, and modernized enterprise workloads. All-in cloud maximizes the benefits of the AWS global infrastructure: auto-scaling, multi-AZ resilience, pay-as-you-go economics, and integration with every AWS service.

Hybrid Deployment

Hybrid deployment connects on-premises data centers to AWS so that workloads span both locations. Hybrid is typical for enterprises in the middle of a multi-year cloud migration, or for workloads with data-sovereignty, latency, or licensing reasons to stay partly on-premises.

The three pillars of hybrid AWS deployment methods:

1. AWS Direct Connect — dedicated private fiber from your data center to an AWS Direct Connect location. Consistent low latency, high bandwidth (1 Gbps, 10 Gbps, 100 Gbps options), traffic does not traverse the public internet. Used for steady, high-throughput hybrid workloads.
2. AWS Site-to-Site VPN — encrypted IPsec tunnel over the public internet between your on-premises VPN device and an AWS Virtual Private Gateway or AWS Transit Gateway. Fast to set up, lower cost than Direct Connect, but variable latency because the public internet carries traffic.
3. AWS Outposts — AWS-managed server racks physically installed in your data center. AWS Outposts extends AWS services (EC2, EBS, RDS, ECS, EKS, S3 on Outposts) to your premises, giving you the AWS API and AWS Management Console experience with local compute. Used for ultra-low-latency, data-residency, or air-gapped use cases.

On-Premises Deployment

On-premises deployment means workloads run entirely in customer data centers but may still use AWS-compatible tooling such as AWS CloudFormation templates, AWS CDK constructs, AWS SDK integrations, or AWS container images for consistency. AWS on-premises AWS deployment methods include AWS Outposts, VMware Cloud on AWS, AWS Local Zones (edge Regions close to metropolitan areas), and Amazon ECS Anywhere / Amazon EKS Anywhere (run AWS container orchestration on your own hardware).

One-Time Operations vs Repeatable Automated Processes

A useful CLF-C02 lens on AWS deployment methods is the difference between one-time operations and repeatable automation.

One-time operations are tasks that you do once, do not expect to repeat, and can safely do by hand. Examples: creating an initial IAM admin user, enabling AWS CloudTrail organization trails, exploring a new AWS service. The AWS Management Console is appropriate here.

Repeatable automated processes are tasks that will happen many times — often, across many accounts and AWS Regions. Examples: provisioning a new environment for every feature branch, rotating IAM credentials monthly, deploying a microservice 50 times a day. The AWS CLI, AWS SDK, AWS CloudFormation, AWS CDK, and AWS Systems Manager are appropriate here.

The CLF-C02 exam rewards candidates who consistently choose Infrastructure as Code and programmatic access AWS deployment methods over AWS Management Console clicks for anything that will be repeated.

APIs — The Foundation Beneath All AWS Deployment Methods

All AWS deployment methods ultimately speak to AWS service APIs — HTTPS endpoints that accept signed requests and return structured responses. The AWS Management Console, AWS CLI, AWS SDK, AWS CloudFormation, and AWS CDK are all API clients.

For CLF-C02 you do not need to memorize API endpoints or signing algorithms. You do need to know:

• Every AWS service exposes an API.
• The AWS CLI, AWS SDK, and AWS Management Console are clients of those APIs.
• AWS CloudFormation calls these APIs on your behalf when it creates a stack.
• AWS Identity and Access Management (IAM) governs who can call which APIs on which resources — this is why AWS deployment methods are inseparable from IAM.

Key Numbers and Must-Memorize Facts

CLF-C02 is a foundational exam and avoids deep numeric trivia, but a few AWS deployment methods numbers appear often:

• 3 primary access methods: AWS Management Console, AWS CLI, AWS SDK.
• 3 deployment models: cloud (all-in), hybrid, on-premises.
• 2 hybrid network options plus AWS Outposts: AWS Direct Connect, AWS Site-to-Site VPN, AWS Outposts.
• AWS Direct Connect bandwidths: 1 Gbps, 10 Gbps, 100 Gbps (hosted connections available at sub-1 Gbps).
• AWS CloudFormation template formats: YAML and JSON.
• AWS CDK supported languages: TypeScript, JavaScript, Python, Java, C#, Go.
• AWS SDK supported languages (CLF-C02 scope): Python, JavaScript, Java, .NET, Go, Ruby, PHP, C++ (plus Swift, Kotlin, Rust).
• AWS Elastic Beanstalk supported platforms: Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker.
• AWS Elastic Beanstalk price: $0 for AWS Elastic Beanstalk itself; you pay for underlying EC2, ELB, EBS, and so on.

Common Exam Traps — Pitfalls to Memorize

Trap 1: "AWS Management Console supports automation"

False. The AWS Management Console is a browser GUI for humans. Automation requires the AWS CLI or AWS SDK. Whenever a CLF-C02 question says "the team needs to automate provisioning," eliminate AWS Management Console from the answer list.

Trap 2: "AWS CloudFormation is imperative"

False. AWS CloudFormation is declarative. You describe the desired state; AWS CloudFormation figures out ordering. An imperative AWS deployment method would be a bash script of AWS CLI commands executed top-down.

Trap 3: "AWS Elastic Beanstalk is a compute service"

False. AWS Elastic Beanstalk is a deployment method. The underlying compute service is Amazon EC2. CLF-C02 Task 3.1 covers AWS Elastic Beanstalk; Task 3.3 covers Amazon EC2 directly.

Trap 4: "AWS CDK replaces AWS CloudFormation"

False. AWS CDK generates AWS CloudFormation templates and uses AWS CloudFormation as its deployment engine. They are complementary, not competitors.

Trap 5: "Direct Connect is always better than VPN"

False. AWS Direct Connect requires physical installation (lead time in weeks) and costs more than AWS Site-to-Site VPN. For quick hybrid connectivity or lower-bandwidth needs, AWS Site-to-Site VPN is the right AWS deployment method.

Trap 6: "AWS Outposts is a form of Direct Connect"

False. AWS Outposts is AWS hardware in your data center, not a network link. You still often pair AWS Outposts with AWS Direct Connect for the backhaul connection to an AWS Region.

Trap 7: "AWS Systems Manager is a deployment method only"

Partial. AWS Systems Manager is primarily an operations service (patching, run command, parameter store) but is included in Task 3.1 because it automates Day-2 operations that follow deployment.

Deployment Methods vs Compute Services — Scope Boundary (3.1 vs 3.3)

The CLF-C02 exam guide separates Task 3.1 (deployment and operation methods) from Task 3.3 (compute services). The boundary:

When CLF-C02 asks "which deployment method would you choose?" the correct answer lives in the left column. When CLF-C02 asks "which compute service runs this workload?" the correct answer lives in the right column. Watching for this boundary prevents the Elastic-Beanstalk-vs-EC2-vs-Lambda trap.

vs Similar Concepts: AWS CloudFormation vs Terraform vs AWS CDK

• AWS CloudFormation: native AWS Infrastructure as Code, YAML/JSON, declarative, supports all AWS services first.
• AWS CDK: wraps AWS CloudFormation in real programming languages (TypeScript, Python, Java, and more).
• HashiCorp Terraform: third-party multi-cloud Infrastructure as Code. Not an AWS service — out of scope for CLF-C02 as an answer but may appear as a distractor. The correct AWS-native answer is always AWS CloudFormation or AWS CDK.

Practice Question Links — Task 3.1 Mapped Exercises

After reading this topic, practice these patterns:

• Match a scenario to the correct AWS deployment method: Management Console, AWS CLI, AWS SDK, AWS CloudFormation, AWS CDK, AWS Elastic Beanstalk.
• Choose between AWS Direct Connect, AWS Site-to-Site VPN, and AWS Outposts for hybrid connectivity.
• Identify which service is a deployment method vs a compute service (Task 3.1 vs Task 3.3).
• Recognize when the correct answer is Infrastructure as Code vs a manual clicking workflow.

FAQ — Deployment & Operation Methods Top Questions

Q1: What are the three main ways to interact with AWS deployment methods on CLF-C02? A: AWS Management Console (browser GUI), AWS CLI (command-line scripting), and AWS SDK (language libraries). All three make the same underlying AWS API calls but serve different workflows: exploration, automation scripts, and in-application integration respectively.

Q2: Is AWS Elastic Beanstalk a compute service or a deployment method on CLF-C02? A: AWS Elastic Beanstalk is classified as a deployment method under Task 3.1. It provisions Amazon EC2 under the hood but is evaluated on the exam as a managed deployment platform. The underlying Amazon EC2 is the compute service under Task 3.3.

Q3: What is the difference between AWS CloudFormation and AWS CDK? A: AWS CloudFormation is the native declarative Infrastructure as Code engine using YAML or JSON templates. AWS CDK lets you write that same infrastructure in real programming languages (TypeScript, Python, Java, C#, Go) and synthesizes it into AWS CloudFormation templates. AWS CDK does not replace AWS CloudFormation — it sits on top of it.

Q4: When should I choose AWS Direct Connect over AWS Site-to-Site VPN for hybrid AWS deployment methods? A: Choose AWS Direct Connect when you need consistent high bandwidth, predictable low latency, and traffic that does not traverse the public internet — typical for enterprise workloads moving large data volumes. Choose AWS Site-to-Site VPN when you need quick setup, lower cost, or encrypted connectivity over an existing internet connection.

Q5: Can I automate the AWS Management Console? A: No. The AWS Management Console is a browser interface for humans. For automation, use the AWS CLI, the AWS SDK, AWS CloudFormation, or AWS CDK. This is a common CLF-C02 trap: if the scenario mentions automation, scheduled jobs, or repeatable deployments, the answer is always programmatic access (AWS CLI, AWS SDK) or Infrastructure as Code (AWS CloudFormation, AWS CDK).

Q6: Does AWS Elastic Beanstalk cost extra beyond the underlying resources? A: No. AWS Elastic Beanstalk itself has no additional fee. You pay only for the AWS resources it provisions on your behalf: Amazon EC2 instances, Elastic Load Balancers, Amazon EBS volumes, and Amazon CloudWatch. This makes AWS Elastic Beanstalk a cost-neutral AWS deployment method relative to running Amazon EC2 directly.

Q7: Is AWS Outposts a hybrid or on-premises AWS deployment method? A: Both, depending on phrasing. AWS Outposts is AWS hardware installed in a customer data center that extends AWS services on-premises. It enables hybrid architectures (typically paired with AWS Direct Connect back to a Region) and is the primary AWS-native answer when CLF-C02 describes "AWS services running in my own data center."

Further Reading — Official AWS Documentation

• AWS CLI User Guide: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html
• AWS SDK overview: https://aws.amazon.com/developer/tools/
• AWS CloudFormation User Guide: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html
• AWS CDK Developer Guide: https://docs.aws.amazon.com/cdk/v2/guide/home.html
• AWS SAM Developer Guide: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html
• AWS Elastic Beanstalk Developer Guide: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html
• AWS Systems Manager User Guide: https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html
• AWS Direct Connect User Guide: https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html
• AWS Site-to-Site VPN User Guide: https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html
• AWS Outposts User Guide: https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html

Mastering AWS deployment methods is the single fastest way to raise your CLF-C02 Domain 3 score. Internalize the three access AWS deployment methods (AWS Management Console, AWS CLI, AWS SDK), the two main Infrastructure as Code tools (AWS CloudFormation, AWS CDK), the managed deployment platform (AWS Elastic Beanstalk), the operations service (AWS Systems Manager), and the three deployment models (cloud, hybrid, on-premises). Every CLF-C02 question under Task Statement 3.1 reduces to choosing the right item from these lists.