DEV Community: Shivam Singh

AWS SAA-C03: Containers, Serverless, DynamoDB & Cognito — 10 Concepts Worth Knowing

Shivam Singh — Thu, 02 Jul 2026 16:20:47 +0000

AWS SAA-C03: Containers, Serverless, DynamoDB & Cognito — 10 Concepts Worth Knowing

This post covers the AWS container, serverless, and database services that appear heavily on the SAA-C03 exam — ECS, EKS, Fargate, Lambda, DynamoDB, API Gateway, Step Functions, and Cognito. For each one, the focus is on what the exam actually tests, not what the documentation says.

1. ECS Launch Types — EC2 vs Fargate

ECS (Elastic Container Service) runs Docker containers on AWS. It has two launch types with completely different operational models:

EC2 Launch Type:

You provision and manage the underlying EC2 instances
The ECS agent runs on each instance and communicates with the ECS control plane
AWS handles starting and stopping containers — you handle the instances they run on
More control, more operational overhead

Fargate Launch Type:

Fully serverless — no EC2 instances to provision, patch, or scale
Define CPU and memory per task; AWS runs it
Just create task definitions and Fargate handles the rest
You pay per task, not per instance

Exam shortcut: Any question containing "no infrastructure to manage," "serverless containers," or "don't want to manage EC2" → Fargate.

2. ECS IAM Roles — Two Roles, Completely Different Jobs

ECS uses two distinct IAM roles. Confusing them is one of the most common exam mistakes:

EC2 Instance Profile (EC2 Launch Type only):

Attached to the EC2 instance, used by the ECS agent
Lets the agent: pull images from ECR, send logs to CloudWatch, access Secrets Manager / Parameter Store
This is infrastructure-level access — the host needs it to run containers

ECS Task Role:

Attached to the task definition — your container's application code uses this
Each service should have its own Task Role with only the permissions it needs
Example: a container that reads from S3 needs an S3 read permission in its Task Role, not in the Instance Profile

The exam trap: A question asks which role allows a container to read from S3. The answer is Task Role — not Instance Profile.

3. EKS — Managed Kubernetes on AWS

EKS (Elastic Kubernetes Service) runs managed Kubernetes clusters. The exam doesn't test Kubernetes internals — it tests when you'd choose EKS over ECS.

Choose EKS when:

The team already uses Kubernetes on-premises or on another cloud
You need cloud-agnostic portability (Kubernetes works on Azure and GCP too)
You're lifting and shifting an existing K8s workload to AWS

EKS node options:

Managed Node Groups: AWS creates and manages EC2 instances in an ASG
Self-Managed Nodes: you create EC2s and register them to the cluster
Fargate: no nodes at all — fully serverless

EKS storage: Uses a Container Storage Interface (CSI) driver. Supported: EBS (single-AZ), EFS (multi-AZ, works with Fargate), FSx for Lustre, FSx for NetApp ONTAP.

Exam shortcut: "Company already uses Kubernetes" = EKS. "Starting fresh on AWS" = ECS.

4. Lambda — The Limits That Appear in Questions

Lambda is a major exam topic and specific numbers appear in exam questions directly:

Limit	Value
Memory	128 MB – 10 GB (1 MB increments)
Max execution time	900 seconds (15 minutes)
Tmp disk (/tmp)	512 MB – 10 GB
Concurrency	1,000 per region (increasable via support ticket)
Deployment zip	50 MB compressed / 250 MB uncompressed
Environment variables	4 KB

Key behaviours:

Increasing RAM also scales CPU and network — they're linked
Container images can be used as Lambda packages (must implement Lambda Runtime API)
For arbitrary Docker images → ECS/Fargate, not Lambda
The 15-minute limit is the most-used exam filter: any workload needing longer than 15 minutes eliminates Lambda as an option

5. Lambda Concurrency — The Regional Throttling Trap

Lambda concurrency is shared across all functions in a region. This creates a specific failure mode the exam tests:

The problem:
All Lambda functions in a region share 1,000 concurrent executions. If one high-traffic function consumes all 1,000, every other Lambda function in that region gets throttled — even completely unrelated ones.

The fix: Set Reserved Concurrency on each function to cap its maximum concurrency and protect the region's shared pool.

Throttle behaviour by invocation type:

Synchronous (API Gateway → Lambda): returns ThrottleError 429 immediately
Asynchronous (S3 event → Lambda): retries automatically, then routes to Dead Letter Queue (DLQ)

Provisioned Concurrency: Pre-warms Lambda execution environments to eliminate cold start latency. Lambda SnapStart (Java only) achieves the same by snapshotting the initialised environment.

6. Lambda at the Edge — CloudFront Functions vs Lambda@Edge

When you need to run logic at CloudFront edge locations, AWS gives you two options:

CloudFront Functions:

JavaScript only
Sub-millisecond startup, millions of requests per second
Can only intercept Viewer Request and Viewer Response
Native CloudFront feature — managed entirely within CloudFront
Use for: URL rewrites, header manipulation, lightweight auth token checks

Lambda@Edge:

Node.js or Python
More compute time, heavier logic
Intercepts all four CloudFront events: Viewer Request, Origin Request, Origin Response, Viewer Response
Use for: complex routing, A/B testing, full authentication at the edge

Lambda in VPC: Lambda runs outside your VPC by default. To reach RDS, ElastiCache, or internal services, deploy Lambda into a VPC subnet with a security group. It uses an ENI to connect.

7. DynamoDB Capacity Modes — Provisioned vs On-Demand

DynamoDB is a fully managed NoSQL database. The exam tests capacity mode selection heavily:

Provisioned Mode (default):

Define Read Capacity Units (RCU) and Write Capacity Units (WCU) in advance
Add auto-scaling to adjust based on CloudWatch metrics
Cheaper per operation for stable, predictable traffic

On-Demand Mode:

Scales instantly with zero capacity planning
Pay per request — more expensive per operation
Right answer for: new applications with unknown traffic, workloads with steep sudden spikes

DynamoDB core model:

Tables made of Items, each with Attributes — flexible schema (attributes can differ per item)
Primary Key: Partition Key alone, or Partition Key + Sort Key (composite)
Max item size: 400 KB
Data types: Scalar (String, Number, Binary, Boolean, Null), Document (List, Map), Sets

Exam shortcut: "Traffic is unpredictable / spike-heavy" = On-Demand. "Steady, cost-sensitive workload" = Provisioned with auto-scaling.

8. DAX vs ElastiCache — Caching DynamoDB Reads

Both are in-memory caches. The exam tests which to use for DynamoDB:

DynamoDB Accelerator (DAX):

Purpose-built for DynamoDB — sits transparently in front of the table
Microsecond read latency for cached items
No application code changes — uses the same DynamoDB API
Caches individual item lookups and query/scan results
Default 5-minute TTL

ElastiCache (Redis or Memcached):

General-purpose cache
Used to store aggregated or computed results (e.g. leaderboard totals, session data)
Requires explicit cache logic in application code — populate, read, and invalidate manually

Exam shortcut:

"Cache DynamoDB reads with no code change" → DAX
"Cache computed or aggregated results" → ElastiCache

9. DynamoDB Streams and Global Tables

DynamoDB Streams:

An ordered, time-stamped log of every item-level change (create, update, delete)
24-hour retention
Trigger Lambda functions in response — the standard serverless event-driven pattern
Use cases: send notifications on new records, replicate to another table, real-time analytics

DynamoDB Global Tables:

Multi-region, active-active replication
Applications can read AND write to the table in any configured region
Changes replicate to all regions automatically
Pre-requisite: DynamoDB Streams must be enabled

TTL (Time to Live): Set an expiry timestamp attribute on any item. DynamoDB deletes expired items automatically at no cost. Use for: session tokens, temporary cache entries, regulatory retention limits.

Exam trap — Global Tables vs RDS Multi-AZ:
RDS Multi-AZ = passive standby, sync replication, failover only — the standby cannot serve writes or reads. DynamoDB Global Tables = active-active, writes in any region. These are completely different patterns and the exam tests whether you know the distinction.

10. API Gateway, Step Functions, and Cognito

API Gateway:

The managed front door for serverless APIs. Handles versioning, environments (dev/prod), auth, throttling, caching, and request/response transformation.

Integration types:

Lambda: expose a REST API backed by Lambda — the most common serverless pattern
HTTP Endpoint: proxy to an internal API or ALB
AWS Service: directly expose SQS, Step Functions, Kinesis through the API layer

Endpoint types:

Edge-Optimised (default): routes through CloudFront edge locations — for global clients
Regional: for same-region clients
Private: VPC-only access via a VPC endpoint (ENI)

Security options: IAM Roles (internal apps), Cognito User Pools (external users), Lambda Authoriser (custom logic).

Step Functions:

Builds visual serverless workflows by orchestrating Lambda functions and AWS services. Supports sequence, parallel execution, conditions, timeouts, error handling, retries, and human approval steps.

Integrates with Lambda, EC2, ECS, on-premises servers, API Gateway, and SQS.

Exam pattern: "Orchestrate multiple Lambda functions" or "multi-step workflow with error handling" → Step Functions.

Amazon Cognito:

Handles user authentication so you don't build it yourself. Two distinct components with different jobs:

Cognito User Pools (CUP):

User directory: sign up, sign in, password reset, MFA, email/phone verification
Supports federated login: Google, Facebook, SAML providers
Returns a JWT token on successful authentication
Integrates directly with API Gateway and ALB — they validate the JWT automatically

Cognito Identity Pools (Federated Identity):

Takes a token (from User Pools or any identity provider) and exchanges it for temporary AWS credentials
Users can then directly access AWS services: S3, DynamoDB, Lambda
IAM policies defined in Cognito, customisable per user_id for fine-grained row-level access

Full pattern:
User logs in → User Pools → JWT → Identity Pools → temporary AWS credentials → direct S3/DynamoDB access.

Exam trigger phrase: "hundreds of users," "mobile users," "federated identity," "authenticate with SAML" → Cognito, not IAM.

The Through-Line

Every service in this section does one thing: removes a layer of infrastructure management.

Fargate removes EC2 from containers
Lambda removes servers from compute
DynamoDB removes database instance management
API Gateway removes API infrastructure
Cognito removes the need to build auth backends
Step Functions removes the need to manage workflow state

The exam tests whether you know which tool removes which layer — and what the limits and edge cases are for each one.

AWS SAA: 10 Core Concepts (Explained for Infrastructure Engineers)

Shivam Singh — Wed, 17 Jun 2026 19:47:06 +0000

This post covers what I learned while preparing for AWS_SAA — IAM, EC2, Load Balancing, Auto Scaling, RDS, Route 53, S3, CloudFront, and messaging services. I'm writing this for engineers who already understand infrastructure, so I'm skipping the basics and going straight to what the exam actually tests.

1. IAM — It's About Least Privilege, Not Just Access

IAM sounds simple until the exam starts testing edge cases. Here's what actually matters:

The model: Users → Groups → Policies. Never attach policies directly to individual users — always go through groups. It sounds obvious but exam questions test whether you know to put a user in a group vs attach a policy inline.

Roles over access keys: When an EC2 instance or Lambda function needs to access AWS services, assign an IAM Role — never embed access keys in code or instance configuration. The exam will present scenarios where someone hardcodes credentials and ask you what's wrong.

The security tools:

IAM Credentials Report (account-level) — lists all users and their credential status
IAM Access Advisor (user-level) — shows which services a user has accessed, helps trim unused permissions

Exam-critical rules:

Root account is only for initial AWS account setup. Never use it for daily operations.
One physical person = one IAM user. No sharing.
MFA on root and privileged users is non-negotiable in exam scenarios.

The policy structure to memorise:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

Effect, Action, Resource — the exam writes scenarios and you need to read policies and spot what's missing or wrong.

2. EC2 Purchasing Options — Architecture Starts Here

The exam gives you a workload description and asks which purchasing option is correct. Memorise these:

Option	When to use
On-Demand	Unpredictable, spiky, short-term workloads
Reserved (1–3 yr)	Steady-state production workloads — biggest discount
Savings Plans	Flexible Reserved — commit to $/hour not instance type
Spot	Fault-tolerant batch jobs, can be interrupted with 2-min notice
Dedicated Host	Compliance requirements, per-socket/per-core software licensing
Dedicated Instance	Isolated hardware, but AWS still manages the host

The exam trap: Spot instances are the cheapest but can be interrupted. Any question about a database, stateful app, or anything that can't tolerate interruption → eliminate Spot immediately.

EC2 Hibernate is a frequent exam distractor — it preserves RAM state to EBS so the instance restarts faster. The root EBS volume must be encrypted. Use case: services that take a long time to warm up.

3. EC2 Storage — EBS vs EFS vs Instance Store

Three storage types, three completely different behaviours:

EBS (Elastic Block Store):

Attached to one EC2 instance at a time (except io1/io2 Multi-Attach)
Persists when you stop the instance
AZ-specific — to move across AZs, take a snapshot

EFS (Elastic File System):

Network file system — can be mounted by hundreds of EC2 instances simultaneously
Works across multiple AZs
Auto-scales, you pay for what you use
Use case: shared content, CMS, web serving across multiple instances

Instance Store:

Physically attached to the host — highest possible IOPS
Completely lost when the instance stops or terminates
Use case: temporary buffers, caches, scratch data only

The exam shortcut:

"Shared across multiple EC2 instances" → EFS
"Highest IOPS, temporary data" → Instance Store
"Persistent, single-instance" → EBS

4. Elastic Load Balancing — Three Types, Different Use Cases

AWS has three load balancer types and the exam tests whether you know which fits which scenario:

Application Load Balancer (ALB) — Layer 7:

Routes based on URL path (/api → one target group, /web → another)
Routes based on hostname (api.example.com vs app.example.com)
Routes based on query strings and headers
Native support for microservices and containers (ECS integration)
Best for HTTP/HTTPS applications

Network Load Balancer (NLB) — Layer 4:

Handles millions of requests per second with ultra-low latency
Has a static IP per AZ — important for whitelisting
Supports TCP, UDP, TLS
Use when you need extreme performance or a fixed IP

Classic Load Balancer (CLB) — Legacy:

Don't design new architectures with it
The exam mentions it but the answer is rarely CLB

Exam pattern: The question describes a routing requirement — you pick the load balancer.

"Route by URL path" → ALB
"Static IP for firewall rules" → NLB
"Microservices on ECS" → ALB

5. Auto Scaling Groups — Four Scaling Policies

ASG lets EC2 scale automatically. The exam tests which scaling policy matches which requirement:

Target Tracking: Simplest. "Keep average CPU at 40%." AWS handles everything.

Step Scaling: "Add 2 instances when CPU > 70%. Remove 1 when CPU < 30%." You define the steps.

Scheduled Scaling: "Increase min capacity to 10 every Friday at 5pm." You know the traffic pattern.

Predictive Scaling: Machine learning-based. Analyses historical load and pre-scales before the spike hits. Best for recurring patterns you can't manually schedule.

The cooldown period: After a scaling activity, ASG waits before scaling again (default 300 seconds). The exam tests this — if instances are launching and terminating in a loop, suspect the cooldown is too short.

6. RDS — Read Replicas vs Multi-AZ (Highest Exam Yield)

This is tested in almost every exam. These two features sound similar and are completely different:

Read Replicas:

Purpose: read scaling — offload SELECT queries from the primary
Replication: asynchronous — slight lag possible
Scope: same AZ, cross-AZ, or cross-region
Network cost: free within same region, charged cross-region
You connect to them explicitly — your app must be updated to use the replica endpoint

Multi-AZ:

Purpose: disaster recovery — automatic failover
Replication: synchronous — always up to date
Scope: same region, different AZ
Failover: DNS automatically points to standby — no app change needed
The standby instance cannot serve read traffic — it exists only for failover

Aurora specifics:

Up to 15 Read Replicas (vs 5 for standard RDS)
Replication lag under 10ms
Aurora Global Database: primary region + up to 10 secondary regions, cross-region replication under 1 second
Aurora Serverless: auto-scales compute — good for infrequent/unpredictable workloads

ElastiCache — the exam trap: ElastiCache is an in-memory cache (Redis or Memcached). The exam often presents a scenario where an RDS database is under heavy read load — the correct answer is frequently "add ElastiCache" rather than more Read Replicas, because cached data never hits the DB at all.

7. Route 53 Routing Policies — Memorise All Six

Route 53 routing policies are one of the highest-density exam topics. Six policies, each with a distinct use case:

Simple: One record, one resource. No health checks. Use for a single server.

Weighted: Split traffic by percentage. Use for A/B testing or canary deployments. Example: 90% to v1, 10% to v2.

Latency: Routes to the region with the lowest latency for the user. AWS measures latency, not geographic distance.

Failover: Active/passive disaster recovery. Primary gets traffic; secondary gets traffic only if primary fails the health check.

Geolocation: Routes based on the user's actual location (country, continent). Use for content localisation or legal data residency requirements. Different from Latency — it's about location, not speed.

Multivalue Answer: Returns up to 8 healthy records randomly. Not a replacement for a load balancer but adds basic client-side load distribution.

TTL matters: High TTL = less Route 53 traffic, but DNS changes take longer to propagate. Low TTL = faster propagation, more Route 53 queries (costs more). The exam tests this trade-off.

8. S3 — Storage Classes and When to Use Each

S3 has seven storage classes. The exam presents a scenario and asks which class is correct:

Class	Availability	Use case
Standard	99.99%	Frequently accessed data
Standard-IA	99.9%	Infrequent access, rapid retrieval — DR, backups
One Zone-IA	99.5%	Single AZ only, cheaper — recreatable data
Glacier Instant Retrieval	99.9%	Archive with millisecond retrieval
Glacier Flexible	99.99%	Archive — minutes to hours retrieval
Glacier Deep Archive	99.99%	Lowest cost — 12+ hour retrieval
Intelligent-Tiering	99.9%	Unknown or changing access patterns — auto-moves

Lifecycle Rules: Automatically transition objects between classes based on age. Example: Standard → Standard-IA after 30 days → Glacier after 90 days. The exam tests whether you know which transitions are valid.

S3 Replication:

CRR (Cross-Region Replication): compliance, lower latency for global users
SRR (Same-Region Replication): log aggregation, live replication between prod and test

Versioning must be enabled on both source and destination buckets for replication to work.

9. S3 Security — Four Encryption Methods

S3 has four server-side encryption options:

SSE-S3: AWS manages keys entirely. Default for new buckets. Header: x-amz-server-side-encryption: AES256

SSE-KMS: You use AWS KMS. You control the key rotation and audit trail via CloudTrail. Header: x-amz-server-side-encryption: aws:kms

SSE-C: You provide your own key with every request. AWS doesn't store the key. HTTPS required. Use when you must control key material.

Client-Side Encryption: You encrypt before uploading. AWS never sees plaintext. Use for strictest compliance requirements.

Bucket Policies vs IAM Policies:

Bucket policies are resource-based — they're attached to the bucket
IAM policies are identity-based — attached to users/roles
Both can allow or deny access. Explicit DENY anywhere always wins.

The CORS trap: If your JavaScript app at example.com calls an S3 bucket, you must configure CORS on the bucket. The exam describes a browser error and asks what's wrong — the answer is CORS.

10. SQS vs SNS vs Kinesis — Decouple vs Stream

Three services, three different problems:

SQS (Simple Queue Service):

Consumers pull messages
Message deleted after consumed
At-least-once delivery (can get duplicates in Standard queue)
FIFO queue: exactly-once, ordered, 300 TPS
Default retention: 4 days, max 14 days
Use for: decoupling microservices, async processing

SNS (Simple Notification Service):

Publisher pushes, all subscribers receive
Messages not persisted — lost if not delivered
Up to 12.5 million subscribers per topic
Use for: fanout notifications, triggering multiple downstream actions

Kinesis Data Streams:

Real-time streaming at high throughput
Data retained up to 365 days — you can replay
Ordering guaranteed per shard
Use for: real-time analytics, log ingestion, clickstream data

The fan-out pattern (exam favourite):
One event → SNS Topic → multiple SQS queues (one per downstream service). This is the go-to pattern when one event needs to trigger multiple independent consumers.

Amazon MQ: When migrating existing on-premises apps that use MQTT, AMQP, or STOMP protocols, use Amazon MQ rather than rewriting for SQS/SNS. The exam presents legacy migration scenarios specifically to test this.

Classic Architecture Patterns — The Mental Model

Every SAA exam scenario is a variation of five building blocks:

Stateless app → don't store sessions in EC2 — use ElastiCache (Redis) or DynamoDB
Shared file storage → EFS, not EBS (EBS is single-instance)
Static content → S3 + CloudFront (never serve static files from EC2)
Read-heavy database → RDS Read Replica or ElastiCache in front
High-write database → Aurora (faster writes, auto-scales storage)

When you see a complex architecture question, strip it back to these five patterns. The correct answer almost always combines two or three of them.

8 Python Patterns a DevOps Engineer Actually Needs for ML

Shivam Singh — Wed, 17 Jun 2026 07:52:24 +0000

I'm a DevOps engineer moving into MLOps.

When I started, I assumed my Python scripting background had me covered. I already wrote automation scripts, parsed YAML, called APIs, handled errors. Python is Python, right?

Wrong.

DevOps Python and ML Python look different, feel different, and break in different ways. After completing a focused Python-for-ML course, here are the 8 patterns that genuinely shifted how I work — written specifically for engineers with a DevOps background.

1. DataFrames over loops

What DevOps engineers do: process data with for loops and lists of dicts.

What ML code does: everything lives in a pandas DataFrame.

# The DevOps way
data = []
with open('data.csv') as f:
    for line in f.readlines()[1:]:  # skip header
        parts = line.strip().split(',')
        data.append({'name': parts[0], 'value': float(parts[1])})

high_values = [d for d in data if d['value'] > 100]

# The ML way
import pandas as pd

df = pd.read_csv('data.csv')
high_values = df[df['value'] > 100]  # done in one line

Why it matters: Every ML library — sklearn, MLflow, XGBoost — expects DataFrames as input. Keep working with lists of dicts and you'll spend half your time converting between formats. Learn the DataFrame mental model first; everything else follows.

2. NumPy arrays for numerical work

What DevOps engineers do: use Python lists. Flexible, familiar, fine.

What ML code does: uses NumPy arrays for anything numerical.

# The DevOps way
numbers = [1, 2, 3, 4, 5]
doubled = [n * 2 for n in numbers]   # loop over each element
squared = [n ** 2 for n in numbers]  # another loop

# The ML way
import numpy as np

numbers = np.array([1, 2, 3, 4, 5])
doubled = numbers * 2    # vectorized — no loop
squared = numbers ** 2   # vectorized — no loop

# Operations across entire arrays in one line
mean = numbers.mean()
std  = numbers.std()
normalized = (numbers - mean) / std

Why it matters: ML regularly works with 10 million data points. At that scale, a Python loop takes minutes; a vectorized NumPy operation takes seconds. The performance difference isn't academic — it determines whether your data pipeline is usable or not.

3. Dataclasses for config management

What DevOps engineers do: YAML files parsed to Python dicts. You know this pattern deeply — Kubernetes, Ansible, Docker Compose all run on it.

What ML code does: hyperparameters and model configs live in Python dataclasses.

# The DevOps way — YAML parsed to a dict
import yaml

config = yaml.safe_load(open('config.yaml'))
learning_rate = config['model']['learning_rate']  # no type checking
batch_size    = config['trainign']['batch_size']  # typo fails at runtime, not at write time

# The ML way — dataclass with types and defaults
from dataclasses import dataclass

@dataclass
class ModelConfig:
    learning_rate: float = 0.001
    batch_size:    int   = 32
    epochs:        int   = 10
    model_name:    str   = "random_forest"
    max_depth:     int   = 5

config = ModelConfig(learning_rate=0.01, epochs=50)
print(config.learning_rate)  # IDE autocomplete works
print(config)                # ModelConfig(learning_rate=0.01, batch_size=32, ...)

Why it matters: ML experiments involve running the same model with hundreds of different hyperparameter combinations. Dataclasses give you autocomplete, type checking (typos caught at write time, not runtime), and they're naturally printable and comparable. They're not a replacement for YAML — they work alongside it for the Python-layer config.

4. Context managers beyond file handling

What DevOps engineers do: you already know with open(). You understand context managers in principle.

What ML code does: extends this same pattern into experiment tracking, GPU management, and timing.

# You already know this
with open('config.yaml') as f:
    config = yaml.safe_load(f)

# ML extends the exact same pattern
import mlflow

mlflow.set_experiment("housing-price-prediction")

with mlflow.start_run(run_name="random_forest_v1"):
    mlflow.log_params({
        "n_estimators": 100,
        "max_depth":    5,
        "learning_rate": 0.01
    })

    # ... train your model here ...

    mlflow.log_metrics({
        "train_accuracy": 0.94,
        "val_accuracy":   0.91,
        "rmse":           42300
    })

    mlflow.sklearn.log_model(model, "model")
# run auto-closes and saves everything, even on exception

Why it matters: You already understand the mental model — the context manager guarantees cleanup. In ML, this pattern appears constantly: experiment tracking, PyTorch GPU contexts, timed blocks, feature store connections. Recognising it means you're never starting from zero.

5. Pathlib over os.path

What DevOps engineers do: os.path.join(), os.makedirs(), os.path.exists().

What ML code does: uses pathlib.Path — the modern Python standard.

import os

# The DevOps way
data_path = os.path.join('data', 'raw', 'train.csv')
model_dir = os.path.join('models', 'experiment_1', 'v2')
os.makedirs(model_dir, exist_ok=True)

if os.path.exists(data_path):
    with open(data_path) as f:
        content = f.read()

from pathlib import Path

# The ML way
data_path = Path('data') / 'raw' / 'train.csv'
model_dir = Path('models') / 'experiment_1' / 'v2'
model_dir.mkdir(parents=True, exist_ok=True)

if data_path.exists():
    content = data_path.read_text()

# Bonus: globbing is clean
all_csvs = list(Path('data').glob('**/*.csv'))

Why it matters: Every ML codebase and library you'll read or contribute to uses pathlib — sklearn, MLflow, PyTorch DataLoaders. Open a PR using os.path and reviewers will ask you to change it. Better to build the habit now.

6. Type hints are not optional in ML

What DevOps engineers do: skip type hints on scripts. Scripts are short-lived and single-purpose — they run, they work, they're done.

What ML code does: enforces type hints because ML code goes to production and lives for years.

# DevOps script — no type hints, fine for a one-off
def process_data(data, threshold):
    return [x for x in data if x > threshold]


# ML production code — type hints are documentation
import pandas as pd
from typing import Optional

def preprocess_features(
    df:            pd.DataFrame,
    target_column: str,
    threshold:     float = 0.5,
    drop_nulls:    bool  = True
) -> tuple[pd.DataFrame, pd.Series]:
    """
    Separate features and target, apply threshold filter.

    Args:
        df:            Raw input DataFrame from data pipeline.
        target_column: Name of the label column to predict.
        threshold:     Minimum value filter for numerical features.
        drop_nulls:    Whether to drop rows with missing values.

    Returns:
        (X, y) tuple ready for sklearn fit().
    """
    if drop_nulls:
        df = df.dropna()
    X = df.drop(columns=[target_column])
    y = df[target_column]
    return X, y

Why it matters: You'll write a preprocessing function today. Someone else — or future you — will call it six months later while debugging a production model. Type hints and docstrings are the difference between "self-explanatory" and "I have to read the entire function to understand what it expects." In ML, functions get reused across experiments for months.

7. Generators for large datasets

What DevOps engineers do: load files into memory. For config files and log snippets, this is perfectly fine.

What ML code does: uses generators to stream large data without running out of RAM.

# DevOps way — loads everything into memory
def load_all_logs(filepath):
    with open(filepath) as f:
        return f.readlines()  # entire file in RAM — fine at 10MB, fatal at 50GB

# ML way — generator, one line at a time
def stream_logs(filepath):
    with open(filepath) as f:
        for line in f:
            yield line.strip()  # constant memory regardless of file size

# The ML pattern you'll use most: batch generator for training
def batch_generator(
    data:       np.ndarray,
    labels:     np.ndarray,
    batch_size: int = 32
):
    """Yields (X_batch, y_batch) pairs without loading all data at once."""
    indices = np.arange(len(data))
    for start in range(0, len(data), batch_size):
        batch_idx = indices[start:start + batch_size]
        yield data[batch_idx], labels[batch_idx]

for X_batch, y_batch in batch_generator(X_train, y_train, batch_size=32):
    model.partial_fit(X_batch, y_batch)

Why it matters: ML training datasets are routinely 10GB–1TB. You cannot pd.read_csv() a 100GB file. Once you understand yield, you'll recognise the same pattern in PyTorch DataLoaders, TensorFlow tf.data pipelines, and every production data pipeline you'll ever build.

8. Experiment logging, not print statements

What DevOps engineers do: print() for debugging, logging for production scripts. You log events and errors.

What ML code does: tracks parameters, metrics, and artifacts across every run so you can compare them.

# The DevOps approach
print(f"Accuracy: {accuracy:.4f}")   # lost when terminal closes
print(f"RMSE: {rmse:.2f}")

import logging
logging.info(f"Model trained. Accuracy: {accuracy}")  # better, but still siloed

# The ML approach — tracked, comparable, reproducible
import mlflow

mlflow.set_experiment("california-housing")

with mlflow.start_run(run_name="xgboost_depth5"):
    mlflow.log_params({
        "model_type":  "XGBoost",
        "max_depth":   5,
        "n_estimators": 200,
        "learning_rate": 0.01,
        "feature_set": "v2_with_distance"
    })

    # ... train your model ...

    mlflow.log_metrics({
        "train_rmse": 38400,
        "val_rmse":   42300,
        "train_r2":   0.96,
        "val_r2":     0.94
    })

    mlflow.sklearn.log_model(model, "model")

# mlflow ui
# Now compare run 1 vs run 47 side-by-side — every param and metric tracked

Why it matters: You'll run the same model with 50 different parameter combinations trying to improve accuracy. Without tracking, by run 20 you'll have no idea which config produced which result. MLflow runs locally or in the cloud — it's the DevOps-familiar way into experiment tracking, built on tools you already recognise.

The mindset shift in one sentence

DevOps Python keeps systems running. ML Python transforms data and trains models.

Same language — different idioms, different patterns, different instincts.

The context manager you already know is the same pattern powering experiment tracking. The YAML config you know is the same concept as a dataclass. The log file you monitor is the same idea as an experiment run.

The bridge is shorter than it looks. You just need to know where it starts.