Search
30 results for “iac”
Search results
Why is scanning IaC source (Terraform files) not sufficient on its own, without also checking the plan?
Static scanning of Terraform source can catch some misconfigurations (a hardcoded insecure default) but can't see values that only exist after variables, data sources, and module composition are actually resolved, an insecure setting could depend on a variable supplied at runtime that static source scanning alone can't evaluate. The plan is the fully resolved, concrete set of resources Terraform is actually about to create or change, which is why policy-as-code tools evaluate the plan, not just the source, as the authoritative point to check against before anything is provisioned.
Terraform Azure Tutorial: How to Create Resource Groups, VNets, Subnets, NSGs, and VMs Step‑by‑Step IaC
Terraform on Azure: Building a Real-World Infrastructure from Scratch.
Automating Azure Infrastructure with Bicep: A Hands-On IaC Lab Using VS Code
Deploying VNets, VMs, IAM, Policies, Monitoring, and Governance using Infrastructure as Code.
Infrastructure as Code Security
How policy-as-code catches a non-compliant infrastructure change at the plan stage, before anything is provisioned, and why that timing is what makes it a real control rather than a post-incident audit trail.
Terraform Basics
How Terraform's declarative state model, providers, and plan/apply workflow let infrastructure be versioned and reviewed like code, and the state pitfalls that trip up most teams.
What problem does policy-as-code solve that a manual infrastructure change review does not?
A manual review depends on a human noticing a specific misconfiguration, an open security group, an unencrypted storage bucket, in a plan diff that may span hundreds of resources, and that scrutiny has to be repeated consistently by every reviewer on every change. Policy-as-code encodes the same rule once as executable logic and runs it automatically against every plan, so an overly permissive security group is caught the same way on the hundredth change as the first, without depending on which reviewer happened to be paying attention that day.
At what point in the Terraform workflow are Sentinel (or similar policy-as-code) checks evaluated, and why does that timing matter?
Policy checks evaluate against the plan, the output of `terraform plan`, before `terraform apply` actually provisions anything, which means a policy violation blocks the run from proceeding to apply at all. Evaluating against the plan rather than the already-applied state is what makes this a preventive control instead of a detective one; the non-compliant resource is stopped before it exists, not flagged for cleanup afterward once it's already live and potentially already been exploited or has already incurred cost.
What is Terraform state and why is it required?
State is a JSON file (by default `terraform.tfstate`) that maps every resource block in your configuration to the real-world object Terraform created for it (an AWS instance ID, a DNS record, etc.). Terraform is declarative, your config describes the desired end state, not the steps to get there, so on every run it needs state to compute a diff between what exists now and what the config says should exist. Without state, Terraform would have no way to know whether a resource already exists, needs updating, or was deleted outside of Terraform.
Why is storing Terraform state locally a problem for a team, and what is the standard fix?
Local state is a single file on one person's machine, a second engineer running `terraform apply` has no idea what the first one already created, so both can independently "discover" no matching state and try to recreate resources, or worse, apply conflicting changes concurrently with no locking. The standard fix is a remote backend (S3+DynamoDB, Terraform Cloud, GCS, Azure Blob) that stores state centrally and supports locking, so only one apply can run at a time and everyone reads the same source of truth.
What is the difference between terraform plan and terraform apply, and why does that separation matter?
`plan` computes and displays the diff between current state and desired config without changing anything; it is a dry run. `apply` executes that diff against real infrastructure. Separating them means a human (or a CI approval gate) can review exactly what will be created, changed, or destroyed before anything actually happens, which is the core safety mechanism that makes infrastructure-as-code safer than manually clicking through a cloud console, nothing changes without a reviewed, explicit plan.
Deploying a Scalable Azure Environment with Bicep: VMs, NSGs, Subnets & Load Balancer (Step-by-Step Lab)
A hands-on IaC walkthrough using VS Code and Bicep to build a secure, highly available Azure environment.
Terraform vs Ansible
Terraform provisions infrastructure and Ansible configures it. How the two tools differ in model, state, and strengths, and how they pair.
Terraform vs Bicep
How Terraform and Bicep differ in state management, cloud scope, and tooling, and which one fits your Azure infrastructure-as-code workflow.
How to Build a Production-Ready Auto-Scaling Azure Web App with Modular Terraform (VMSS, Load Balancer & NAT Gateway)
From Basic Terraform to Production IaC: Building an Auto-Scaling Azure Web App with Modular Terraform.
What is a managed identity, and what problem does it solve compared to a service principal with a client secret?
A managed identity is an Entra ID identity automatically managed by Azure for a resource (a VM, an App Service, a Function), with credentials that Azure handles entirely, no client secret is ever stored, retrieved, or rotated by the application. A traditional service principal with a client secret requires that secret to be stored somewhere (a config file, a key vault) and rotated manually or via automation, which is itself a credential-management burden and a leak risk. Managed identities remove that burden for the common case of "this Azure resource needs to authenticate to another Azure service," which is why they're preferred whenever the workload runs on Azure compute.
What is the difference between `[ ]` and `[[ ]]` in Bash conditionals?
`[ ]` is the POSIX test command, an actual command whose arguments undergo the shell's normal word-splitting and globbing before it ever sees them, which is why an unquoted variable inside it can break in surprising ways. `[[ ]]` is a Bash keyword with special parsing: it does not word-split or glob its arguments, supports pattern matching (`==`, `=~`) and logical operators (`&&`, `||`) directly inside the brackets, and is generally the safer, more predictable choice in Bash-specific scripts, at the cost of not being portable to a strict POSIX `/bin/sh`.
What is a deployment gate, and why put one between CI and production?
A deployment gate is a checkpoint, automated (a canary health check, a manual approval, a change-freeze window), that must pass before a build progresses to the next environment. It exists because passing CI only proves the code works in isolation; it doesn't prove the deployment itself will succeed, or that now is a safe time to deploy (e.g., not during a change freeze, not without on-call coverage). Gates let teams keep deployments frequent and automated while still retaining a control point for the decisions that genuinely need human or environmental judgment.
What is the difference between a reserved/committed-use discount and a spot/preemptible instance, and when does each make sense?
A committed-use discount (reserved instances, savings plans) trades a usage commitment, a fixed amount of spend or capacity over a term, typically one or three years, for a significant price reduction on workloads you know will run continuously. Spot/preemptible instances offer a much steeper discount in exchange for the provider being able to reclaim the capacity with little notice, making them suitable only for interruption-tolerant workloads (batch jobs, stateless workers, CI runners) rather than anything requiring guaranteed uptime. Committed-use addresses predictable steady-state load; spot addresses flexible, interruption-tolerant load, using either for the wrong workload type either wastes the discount or causes outages.
What is a shard key, and why does a low-cardinality shard key (few distinct values) cause a hot shard?
A shard key is the field (or fields) a sharded database uses to decide which shard each document or row actually lives on. If that field has few distinct values, say `country`, and the real data is skewed (80% of users in one country), the vast majority of documents route to the same shard regardless of how many shards exist in the cluster, overwhelming it with disproportionate read/write load and storage while other shards sit comparatively idle. Cardinality alone doesn't guarantee even distribution either, the values also need to actually occur with reasonably even frequency in the real data, not just theoretically have many possible values.
Why is publishing a port with `-p 8080:80` different from the container just "having" port 80?
A container's ports exist only on its own private network namespace by default; nothing on the host or outside can reach them until Docker explicitly forwards a host port to it. `-p 8080:80` tells Docker's network layer to forward the host's port 8080 to port 80 inside the container's namespace, host port first, container port second. Leaving a port `EXPOSE`d in a Dockerfile only records metadata/documentation, it has no effect on connectivity at all: another container on the same Docker network can already reach any port the first container is listening on, EXPOSE or not. Publishing to the host is the one thing that always requires an explicit `-p`.
What is the difference between ss and the older netstat command, and why would you reach for ss first?
Both report socket/connection information, but ss reads directly from kernel data structures and can display considerably more TCP and socket state detail than netstat, including fine-grained state groupings like every "connected" state (everything except listening and closed) or every "synchronized" state, which makes targeted filtering much easier. netstat has been effectively superseded across current Linux distributions, and ss is the tool actively maintained as part of the iproute2 suite alongside ip, which is why it is the modern default for socket inspection rather than a mere alternative.
What is a visibility timeout, and what problem does it solve that simply having multiple consumers poll a queue would create?
When a consumer receives a message, the queue doesn't delete it immediately, it starts a visibility timeout during which that message is hidden from other consumers, so a second consumer polling the same queue won't also pick up and process the same message concurrently. The consumer is expected to finish processing and explicitly delete the message before the timeout expires; if it does, the message never reappears. Without this mechanism, multiple consumers competing for messages would routinely double-process the same one, exactly the race condition visibility timeouts exist to prevent.
What is an Internal Developer Platform (IDP), concretely?
An IDP is the layer, often a combination of a self-service portal/CLI, templated infrastructure (via Terraform modules, Kubernetes operators, or similar), and standardized CI/CD pipelines, that lets a product engineer provision what they need (a new service, a database, a queue) without filing a ticket or becoming an expert in the underlying infrastructure. It sits between raw cloud/Kubernetes primitives and the product engineers who need to consume them, and its quality is measured the same way any product's is: by whether its users (internal engineers) actually prefer using it over working around it.
What is the difference between a composite index and two separate single-column indexes?
A composite (multi-column) index on (a, b) stores rows sorted by a, then by b within each a. It efficiently serves queries filtering on a alone, or on a and b together, but not on b alone. Two separate single-column indexes let Postgres combine them via a bitmap AND/OR, which works but is usually slower than one well-ordered composite index for the common query pattern. Column order in a composite index should match the most selective, most-frequently-filtered column first.
What is a stale closure and how does it happen with useEffect?
A stale closure happens when a function captures a variable from a render that is no longer current, because the effect or callback was not re-created when that variable changed. Classic case: an effect with an empty dependency array reads a piece of state, since the effect only runs once, the function it closes over always sees the state value from the first render, not the latest one. The fix is to include the variable in the dependency array (or use a functional state update that does not need to read the outer value at all).
A component's state is preserved when a prop changes, but reset when a completely different element renders in the same spot. What determines which happens?
React associates state with a component's position in the render tree, not with the component instance or its props specifically. If the same component type renders at the same tree position across a re-render, its state is preserved regardless of what props changed. If a different component type (or a different element entirely) renders at that same position, React treats it as a genuinely different thing, destroys the old state, and starts fresh. This is why toggling a prop on the same `<Counter />` keeps its count, but swapping `<Counter />` for a `<p>` at that same spot in the tree resets it entirely, even though from the JSX it might look like a small, local change.
What is the difference between a parameterized query and simply concatenating a sanitized string?
A parameterized query sends the SQL command and the user-supplied values as two separate things to the database driver, the driver (or the database itself, for prepared statements) binds the values into the query plan without ever treating them as part of the SQL text. String concatenation, even "sanitized," still builds one text string where user input and SQL syntax share the same channel, any gap in the sanitization logic can be exploited. Parameterization removes that shared channel entirely rather than trying to police it.
What is a pytest fixture, and what problem does it solve compared to manual setup/teardown?
A fixture is a function decorated with `@pytest.fixture` that provides a reusable piece of test setup (a database connection, a temp directory, a configured client) which pytest automatically injects into any test function that declares it as a parameter. It solves the same problem as `unittest`'s `setUp`/`tearDown` methods, but as small, composable, independently reusable functions rather than one monolithic method per test class, a test can request exactly the fixtures it needs, and fixtures can depend on other fixtures, building up complex setup from simple, testable pieces.
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.
What is the difference between a client tool and a server tool, and why does that distinction matter for what your application has to do?
A client tool executes in your own application, the model only returns the structured request to call it; your code is responsible for actually running it (hitting your database, calling your API) and returning the result. A server tool, like a web search or code execution tool a provider offers, executes on the provider's own infrastructure, so your application sees the final result directly without ever writing execution code for it. The distinction determines how much you have to build: every client tool needs your own execution and error-handling code, while server tools need none, just declaring them in the request.