Search
30 results for “fundamentals”
Search results
Azure Fundamentals
How Azure organizes resources through management groups, subscriptions, and resource groups, and why that hierarchy, not the resources themselves, is where most governance actually happens.
Bash Fundamentals
The scripting layer built on top of the shell - variables, conditionals, loops, and functions - and the quoting and exit-status habits that separate a script that looks right from one that fails safely.
Cloud IAM Fundamentals
How identity, roles, and policies fit together across cloud providers, why least-privilege is a discipline rather than a one-time setup, and the difference between authentication and authorization.
Cloud Networking Fundamentals
How virtual private clouds, subnets, and security groups model network isolation in the cloud, and why "public" vs "private" subnet is a routing decision, not a labeling one.
Docker Fundamentals
How images, containers, volumes, and networks fit together in Docker's runtime model, and the mental shift from "installing software" to "running a packaged image" that trips up newcomers.
Git Fundamentals
How the working directory, staging area, and commit history actually relate to each other, and why understanding that three-stage model makes branching, rebasing, and undoing changes stop feeling arbitrary.
Kubernetes Fundamentals
How Pods, Deployments, and Services fit together, what the control loop actually does, and why Kubernetes networking confuses people coming straight from Docker Compose.
Linux Fundamentals
The core command-line building blocks - navigation, permissions, processes, networking, and services - that every other Linux topic on this site (filesystem hierarchy, storage, users, networking) assumes you already have.
LLM Fundamentals: Tokens, Context Windows & Sampling
Why a token isn't a word, what actually happens when a request would exceed the context window, and what temperature and top_p each control during generation.
Observability Fundamentals
How logs, metrics, and traces answer different questions, why "we have monitoring" isn't the same as being able to debug an incident, and the cardinality trap that breaks metrics systems.
Platform Engineering Fundamentals
What an internal developer platform actually is, why "golden paths" beat unlimited flexibility, and how platform engineering differs from just having a good DevOps team.
PostgreSQL Fundamentals
How tables, joins, aggregates, window functions, and transactions fit together in everyday PostgreSQL work, from the actual internals of a single index (covered in PostgreSQL Indexes) to the SQL you write day to day.
Python Syntax Fundamentals
How Python's significant whitespace, dynamic typing, and object model shape idiomatic code, and the mutable-default-argument trap that catches almost everyone once.
Web Accessibility Fundamentals
Why the W3C's own first rule of ARIA is to avoid ARIA whenever a native HTML element already does the job, and what WCAG's 4.5:1 versus 3:1 contrast ratios actually apply to.
Big O Notation
How to read and reason about Big O time and space complexity, with the common growth rates ranked and worked examples for each.
What does O(n) actually mean?
It means the algorithm's work grows linearly with input size n, double the input, roughly double the work. Big O describes the worst-case growth rate as n gets large, ignoring constant factors and lower-order terms: an algorithm that does 3n + 100 operations is still O(n), because for large n the constant 100 and the multiplier 3 stop mattering compared to how n itself grows.
Why does an O(n log n) sort beat an O(n^2) sort for large inputs, even if the O(n^2) one is faster on small inputs?
Constant factors can make an O(n^2) algorithm faster for small n, Big O only describes the asymptotic trend, not the exact runtime. But growth rates diverge fast: at n = 1,000,000, n log n is about 20 million operations while n^2 is a trillion. Past a crossover point the asymptotically better algorithm always wins, which is why production sort implementations (like Timsort) still often special-case small arrays with a simpler O(n^2) sort under the hood.
What is the difference between time complexity and space complexity?
Time complexity describes how the number of operations grows with input size; space complexity describes how additional memory usage grows with input size. An algorithm can trade one for the other, memoization in dynamic programming typically turns exponential time into polynomial time by spending O(n) or more extra space to cache results.
Why does Python use indentation instead of braces to define code blocks, and what problem does this create?
Python uses indentation as syntax specifically to force a consistent visual structure, code that looks nested is nested, with no possibility of a brace mismatch making the visual and actual structure disagree, a real class of bugs in brace-delimited languages. The trade-off is that whitespace becomes semantically meaningful: mixing tabs and spaces, or an accidentally misaligned line, is a syntax error (or worse, silently changes which block a line belongs to) rather than a cosmetic issue. Python 3 disallows mixing tabs and spaces in the same file specifically to prevent the silent version of this problem.
Why is using a mutable object (like a list) as a default argument value a common bug in Python?
Default argument values are evaluated exactly once, when the function is defined, not on every call, so a mutable default like `def f(items=[])` creates one list object that is shared across every call that doesn't explicitly pass its own `items`. Appending to it in one call leaves those items present the next time the function is called with the default, which looks like inexplicable state leaking between unrelated calls. The fix is defaulting to `None` and creating a new list inside the function body when `items is None`, so every call that needs the default gets its own fresh object.
What is the difference between `is` and `==` in Python?
`==` calls the object's `__eq__` method and checks value equality, whether two objects represent the same value, even if they are different objects in memory. `is` checks identity, whether two names refer to the exact same object in memory. Two separate list literals with identical contents are `==` but not `is`, because they're distinct objects with equal values. `is` is correct for comparing against singletons like `None` (`x is None`, not `x == None`), since there is exactly one `None` object and identity is the more precise, idiomatic check.
Linux Beginner Labs: Foundations (Understand Linux, Not Just Commands)
This lab helps you understand how Linux works internally, not just type commands. By the end of these labs, Linux will feel logical, not intimidating. Before You Start The Lab (Very Important). What You Need You can use any Linux environment : Ubuntu Desktop / Server Linux VM Cloud VM WSL (Windows…
What is the fundamental unit of isolation in AWS, and how does that differ from a single resource-group boundary in Azure?
In AWS, the account itself is the fundamental security and billing isolation boundary, every resource lives inside exactly one account, and account-level separation is what actually contains blast radius (a compromised credential in one account cannot directly touch resources in another). This differs from Azure, where a single subscription can contain many resource groups as an additional lifecycle boundary beneath it. AWS has no equivalent nested container inside an account for "delete everything in this group together," which is why multi-account strategies (via AWS Organizations) do the job that resource groups partly do in Azure, at the account level instead of a sub-account level.
What is fixture scope, and why is choosing the wrong one a common source of confusing test failures?
Scope (`function`, `class`, `module`, `session`) controls how often a fixture is torn down and recreated, `function` scope (the default) creates a fresh instance for every test, while `session` scope creates it once for the entire test run and shares it across every test that requests it. Choosing a broader scope than a fixture's state can safely support is a common bug: a `session`-scoped fixture holding mutable state (like a database connection with data inserted by one test) leaks that state into every other test sharing it, causing tests to pass or fail depending on run order, a difficult, non-deterministic failure to debug.
A client sends a sudden spike of requests that exceeds the configured rate, but the API doesn't immediately reject any of them. Why not, and when does rejection actually start?
The token bucket has accumulated capacity up to the burst limit, if the client had been under the rate limit recently, unused tokens built up in the bucket, and that reserve absorbs a short spike without any request failing, exactly the point of separating burst capacity from steady-state rate. Rejection (a 429 response) only starts once the bucket is actually empty, every accumulated token has been consumed and the spike is sustained long enough that the rate of token consumption keeps exceeding the rate of token replenishment. This is why a token bucket, unlike a hard per-second cap, tolerates brief bursts gracefully while still enforcing a real steady-state ceiling.
If a microtask itself queues another microtask while it's running, does that new microtask wait for the next event loop iteration, or does it still run before the next macrotask?
It still runs before the next macrotask. The rule isn't "run the microtasks that were queued when this iteration started", it's "drain the microtask queue completely," and if executing a microtask adds another one, that new one is still part of the queue being drained. This means a chain of microtasks that keep scheduling more microtasks can, in principle, starve the event loop from ever reaching the next macrotask (a real, documented way to accidentally block timers and rendering), which is different from a single flat batch of microtasks all queued up front.
What is the difference between durability and availability in S3, and why does it matter when picking a storage class?
Durability is the probability that a stored object is not lost over a year, and S3 Standard, Standard-IA, and every Glacier class are all designed for the same 99.999999999% (11 nines) durability. Availability is how often the object can actually be successfully retrieved on demand, and that number does vary by class, 99.99% for Standard down to 99.5% for One Zone-IA. It matters because a cheaper class is not automatically a less durable one, S3 One Zone-IA is exactly as durable as Standard-IA per object, but it is not resilient to the loss of its single Availability Zone at all, since it isn't replicated across multiple zones the way every multi-AZ class is.
Why does using a monotonically increasing field (a sequential ID, a timestamp) as a shard key concentrate all new writes onto one shard, even with range-based sharding across many shards?
With range-based sharding, chunks are assigned contiguous ranges of shard-key values, and a monotonically increasing key means every new document's value is higher than every previously inserted one, so all new inserts land in whatever chunk currently owns the highest range, which lives on one specific shard. Every other shard, holding older, lower-valued ranges, receives none of the new write traffic at all, the exact "hot shard" problem, all insert load concentrated on a single shard regardless of how many total shards the cluster has.
AI Engineer Roadmap
From LLM fundamentals and prompt engineering through embeddings, retrieval-augmented generation, tool use, and evaluation, the core path for building real LLM-powered applications, linked into Cloud Tech by Victor topic references.
Backend Developer Roadmap
A structured path through the data, API, caching, security, and scaling fundamentals every backend engineer needs, each step links straight into a full Cloud Tech by Victor reference.