Module 8: Deployment, Operations, and Accessing AWS

Step 1 – How People and Systems Access AWS (Big Picture)

In this module, you will see how you and your applications actually talk to AWS.

At a high level, there are four main ways to access AWS services:

1. AWS Management Console

• A web UI (in your browser) for humans.
• Good for: learning, one‑off tasks, visual dashboards.

1. AWS Command Line Interface (CLI)

• A text-based tool you run in a terminal (PowerShell, bash, etc.).
• Good for: scripting, automation, repeating the same tasks reliably.

1. AWS SDKs (Software Development Kits) and APIs

• Libraries for languages like Python, JavaScript, Java, C#, Go, etc.
• Good for: letting your applications call AWS directly (for example, an app uploading files to S3).

1. Infrastructure as Code (IaC) tools

• You define your infrastructure in code or templates instead of clicking in the console.
• AWS-native tool: AWS CloudFormation.
• Also common (but beyond CLF-C02 detail level): Terraform, CDK, etc.

You will also learn about operations and monitoring services that watch what is happening in your AWS account:

• Amazon CloudWatch – metrics, logs, alarms.
• AWS CloudTrail – records who did what, and when (API call history).
• AWS Config – tracks configuration changes and compliance.
• AWS Trusted Advisor – automated best-practice checks (cost, security, etc.).

Keep the exam angle in mind: CLF-C02 expects you to recognize which tool/service is appropriate in a scenario, not to write production-grade automation.

Step 2 – AWS Management Console: The Human-Friendly Interface

The AWS Management Console is usually your first contact point with AWS.

What it is

• A web-based GUI at `https://console.aws.amazon.com`.
• You log in using an IAM user, IAM Identity Center (formerly AWS SSO), or root user (not recommended for everyday use).

What you can do there

• Search for and open services like EC2, S3, RDS.
• Create and configure resources with forms and wizards (e.g., create an EC2 instance by filling in fields).
• View dashboards and metrics (e.g., CloudWatch graphs).
• Use service-specific consoles (e.g., S3 bucket file browser, Lambda code editor).

Visual description

Imagine the console as a control panel:

• Top search bar: type `S3`, `EC2`, etc.
• Left menus: navigate between resource lists and settings.
• Center: main workspace showing tables, charts, or configuration pages.

When to choose the Console (exam perspective)

• You are new to AWS and want to explore.
• You need to quickly check or change a single resource.
• A scenario mentions clicking through a web interface or non-technical stakeholders reviewing resources.

If a question mentions visual dashboards, one-time setup, or a non-programmer user, the Management Console is usually the right answer.

Step 3 – Thought Exercise: Console vs CLI vs SDK

Consider these three mini-scenarios. For each, decide which access method fits best: Console, CLI, or SDK.

1. Scenario A: A student wants to quickly upload a few files to an S3 bucket and check that they are visible.
2. Scenario B: A DevOps engineer needs to rotate log files every night and move them from one S3 bucket to another automatically.
3. Scenario C: A web application written in Python needs to upload user profile pictures directly to S3 when users click "Save".

Pause and decide your answers before reading the suggestions below.

Suggested answers:

• Scenario A → Console: Easy, one-time manual task with a graphical interface.
• Scenario B → CLI (or IaC/script): Needs automation and repeatability (a scheduled script using AWS CLI or similar).
• Scenario C → SDK: The application code needs to talk to AWS (e.g., using the AWS SDK for Python (boto3)).

Use this kind of reasoning on the exam: Who or what is talking to AWS (human vs script vs app)? That usually points to Console vs CLI vs SDK.

Step 4 – AWS CLI and SDKs: Let Scripts and Apps Talk to AWS

The AWS CLI and SDKs use the same underlying AWS APIs, but in different contexts.

AWS Command Line Interface (CLI)

• Installed on your machine or in a server/CI environment.
• You authenticate with access keys or SSO/Identity Center.
• Ideal for automation scripts and repeating tasks.

Example: listing S3 buckets with the AWS CLI:

```bash

Configure your CLI (done once)

aws configure

Then list all S3 buckets in your account

aws s3 ls

```

AWS SDKs (for applications)

• Language-specific libraries: boto3 (Python), AWS SDK for JavaScript, etc.
• Used inside your application code.

Example: uploading a file to S3 using Python (boto3):

```python

import boto3

s3 = boto3.client("s3")

s3.upload_file(

Filename="local_photo.jpg",

Bucket="my-example-bucket",

Key="images/local_photo.jpg"

)

```

You do not need to memorize syntax for the exam, but you should know:

• CLI → used in shell/terminal, good for scripts and admins.
• SDK → used in application code, good for developers building apps.

If a question mentions PowerShell/bash scripts, think CLI. If it mentions code in Python/JavaScript/Java, think SDK.

Step 5 – Infrastructure as Code and AWS CloudFormation (Conceptual)

Modern teams avoid manually clicking in the console for every change. Instead, they use Infrastructure as Code (IaC).

What is Infrastructure as Code?

• You define your infrastructure in files (YAML/JSON or higher-level languages).
• These files describe resources like VPCs, subnets, EC2 instances, S3 buckets, etc.
• Benefits: repeatable, version-controlled, testable, and documented.

AWS CloudFormation (AWS-native IaC)

CloudFormation is AWS’s primary IaC service.

Concepts:

• Template: A file (YAML/JSON) describing your resources.
• Stack: A deployed instance of that template (the actual resources in your account).
• You create/update/delete stacks; CloudFormation figures out what to create, change, or remove.

Very high-level example of a CloudFormation snippet (YAML):

```yaml

Resources:

MyBucket:

Type: AWS::S3::Bucket

Properties:

BucketName: my-example-bucket-12345

```

You do not need to write CloudFormation for CLF-C02. You just need to recognize:

• If the scenario mentions templates, stacks, repeatable deployments, or version-controlling infrastructure, the best answer is usually AWS CloudFormation.
• CloudFormation helps avoid configuration drift (resources becoming inconsistent over time).

Historically, teams often used only the console or manual scripts. IaC with CloudFormation became standard because it reduces human error and makes deployments more reliable and auditable.

Step 6 – Monitoring with Amazon CloudWatch

Amazon CloudWatch is AWS’s main monitoring and observability service.

What CloudWatch does

• Collects metrics: CPU utilization, network traffic, request counts, etc.
• Stores logs: application logs, Lambda logs, system logs.
• Creates alarms: trigger actions when metrics cross thresholds.
• Provides dashboards: graphs and visualizations.

Typical exam associations

• CloudWatch Metrics: “CPU usage of an EC2 instance,” “number of requests to an ALB,” etc.
• CloudWatch Logs: “view Lambda function logs,” “troubleshoot a failing application.”
• CloudWatch Alarms: “send an SNS notification when CPU > 80% for 5 minutes,” “scale out an Auto Scaling group.”

If a question mentions performance, resource utilization, logs, or alarms, CloudWatch is the likely answer.

Visual description: imagine a dashboard with line charts showing CPU usage over time, plus a table of log events you can filter and search.

Step 7 – Governance and Auditing: CloudTrail, Config, Trusted Advisor

Three services often appear together in foundational questions:

1. AWS CloudTrail – “Who did what, and when?”

• Records API calls and console actions in your account.
• Example: User Alice called `RunInstances` on EC2 at 10:32 UTC from IP X.
• Useful for security investigations, audits, and change tracking.

Key phrase: API activity history or audit trail → think CloudTrail.

2. AWS Config – “What does my environment look like, and how has it changed?”

• Records the configuration state of AWS resources over time.
• Can check resources against rules (e.g., all S3 buckets must be encrypted).
• Helps with compliance and governance.

Key phrase: configuration history, compliance rules, resource inventory → think AWS Config.

3. AWS Trusted Advisor – “Am I following best practices?”

• Runs automated checks across your account in categories like:
• Cost optimization (unused resources)
• Performance
• Security (e.g., public S3 buckets)
• Fault tolerance
• Service limits (quotas)
• Shows recommendations and potential savings.

Key phrase: best-practice checks, cost-saving recommendations, security recommendations → think Trusted Advisor.

CLF-C02 often tests your ability to match each service to its primary purpose in scenario questions.

Step 8 – Quick Check: Access Methods

Test your understanding of how to choose between Console, CLI, and SDKs.

Step 9 – Quick Check: Monitoring and Governance Services

Match the described need to the correct AWS service.

Step 10 – Flashcard Review: Key Terms and Services

Flip through these flashcards to reinforce the main concepts from this module.