Search
29 results for “shell”
Search results
Automating Active Directory User and Group Management with PowerShell
Step-by-step lab: creating users, OUs, security groups, and group memberships using PowerShell
Azure Networking with PowerShell: VNets, Peering, Network Watcher
A hands-on lab deploying VNets, peering them securely, provisioning Windows Server VMs, and validating connectivity with Network Watcher.
Bash Fundamentals
Bash scripting from variables to functions, plus the quoting and exit-status habits that separate a script that looks right from one that fails safely.
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`.
Why does `set -euo pipefail` matter at the top of a script?
By default, Bash keeps executing after a command fails, treats referencing an unset variable as an empty string instead of an error, and reports a pipeline's exit status as only its last command's; all three hide real failures. `-e` exits on a non-zero status from most simple commands, but only in contexts where errexit actually applies; it does not trigger inside `if`/`while`/`until` conditions, for any but the last command in a pipeline (unless combined with `pipefail`), or for a non-final command in a `&&`/`||` list, whose status is checked by the operator itself rather than causing an exit. The final command in that list is not exempt, though: if it fails and the list isn't itself acting as an `if`/`while`/`until` condition or the left side of another `&&`/`||`, errexit still triggers. `-u` turns an unset-variable reference into an error, and `-o pipefail` makes a pipeline fail if any stage fails, not just the last one. Together they turn a script that silently continues past errors into one that fails loudly in the cases where errexit applies, which is almost always what you want for anything beyond a one-off interactive command, but it is not a blanket guarantee that catches every failure everywhere.
Why should variables almost always be quoted, e.g. `"$name"` instead of `$name`?
An unquoted variable expansion undergoes word-splitting (on whitespace) and globbing (on `*`, `?`, etc.) before the command sees it, so a value containing a space or a shell metacharacter silently becomes multiple arguments or an unintended file-glob expansion instead of one literal string. Quoting (`"$name"`) suppresses both, so the variable's value is always passed through as exactly one argument, which is why nearly every Bash style guide treats an unquoted variable expansion as a latent bug rather than a style preference.
The Tiny Tool That Would Have Stopped a Production Deploy Gone Wrong
Use direnv to load project-specific environment variables on entry, restore prior shell state on exit, and reduce wrong-account Terraform deploys.
Linux Foundations: How Linux Really Works, Not Just Commands
Learn how Linux actually works (the shell, processes, users, permissions) so commands make sense instead of being memorized one at a time.
Securing Azure Blob Storage: Network Rules, SAS, Immutability
A hands-on lab automating secure Azure Blob Storage using VNets, subnets, SAS tokens, and immutability.
What is Azure Resource Manager (ARM) and why does every Azure operation go through it?
ARM is the deployment and management layer that every Azure operation, whether from the Portal, CLI, PowerShell, or an ARM/Bicep template, ultimately goes through. It provides a consistent API surface, handles authentication and authorization checks against Azure RBAC, and is what enables declarative deployment (submit a template describing desired resources, ARM figures out what to create/update). Because every path converges on ARM, access control and activity logging are consistent regardless of which tool was used to make a change.
Linux Security and Hardening: SSH, Firewalls, Permissions
How Linux Protects Itself and How Administrators Make It Safer.
Scalable Azure Environment with Bicep: VMs, NSGs, Load Balancer
A hands-on IaC walkthrough using VS Code and Bicep to build a secure, highly available Azure environment.
How do management groups extend governance above the subscription level?
Management groups let an organization apply policies (via Azure Policy) and role assignments (via Azure RBAC) across multiple subscriptions at once, instead of configuring each subscription independently. They form a hierarchy above subscriptions, a root management group can contain child management groups (e.g., by department or environment type), each containing multiple subscriptions, so a single policy assignment at the right level of that hierarchy can enforce a rule (like "no public IP addresses" or "must use approved regions") across every subscription beneath it.
What is the difference between locally redundant storage (LRS), zone-redundant storage (ZRS), and geo-redundant storage (GRS)?
LRS replicates data three times within a single datacenter; it protects against hardware failure but not a datacenter-level outage. ZRS replicates synchronously across three availability zones within one region, protecting against a single datacenter failure while keeping data within the region. GRS replicates asynchronously to a second, geographically distant region on top of LRS in the primary region, protecting against a regional disaster at the cost of the secondary copy lagging slightly behind (eventual, not synchronous, consistency) and being unreadable by default unless read access is explicitly enabled (RA-GRS).
What does the principle of least privilege mean in practice, and why is it hard to maintain over time?
Least privilege means granting an identity only the specific permissions it needs to do its job, nothing broader "to be safe" or "to save time." It's hard to maintain because permissions tend to accumulate, someone gets a broad role to unblock a one-time task and it's never revoked, or a service starts with wildcard permissions during initial development and nobody narrows them before shipping. Maintaining least privilege requires ongoing review (access audits, unused-permission detection), not just a careful initial setup, because the natural drift over time is always toward more access, not less.
What does the Kubernetes control loop actually do?
Every Kubernetes controller (Deployment, ReplicaSet, etc.) runs a reconciliation loop: it continuously compares the desired state (what you declared in a manifest, stored in etcd) against the observed actual state of the cluster, and takes action to close any gap. If you declared 3 replicas and only 2 Pods are running, the ReplicaSet controller creates one more. This is the same declarative, converge-toward-desired-state model as Terraform, but running continuously and automatically rather than on-demand.
What is the difference between the Baseline and Restricted Pod Security Standards levels, and why are they cumulative?
Baseline blocks the most well-known container privilege-escalation paths, privileged containers, host namespaces, hostPath volumes, dangerous Linux capabilities, while still allowing a fairly permissive pod spec otherwise. Restricted inherits every Baseline rule and adds real hardening on top: it requires running as non-root, forbids privilege escalation outright, requires a restricted seccomp profile, and requires dropping all Linux capabilities except NET_BIND_SERVICE. A read-only root filesystem is not part of either standard, it's a separate hardening measure some organizations layer on as their own policy, on top of, not as part of, Restricted. They're cumulative by design, Restricted is Baseline plus more, so a workload that passes Restricted automatically satisfies Baseline too, and a cluster can apply different levels per namespace based on how much a given workload can be trusted.
How does Kubernetes RBAC decide whether a request is allowed, and can you write an explicit deny rule?
RBAC is default-deny and purely additive: a request is denied unless some Role/RoleBinding or ClusterRole/ClusterRoleBinding explicitly grants it, and there is no such thing as an explicit deny rule. Every applicable binding's permissions are unioned together, so restricting access means removing a grant (or removing the subject from a binding), not adding a deny statement on top of an existing grant, an approach that works cleanly for grant-based access but has no mechanism for "allow everything except X" within RBAC itself.
What is the difference between killing a process with SIGTERM and SIGKILL?
`kill <pid>` sends SIGTERM by default, a request asking the process to shut down, which well-behaved programs catch to close files, finish in-flight work, and exit cleanly. `kill -9 <pid>` sends SIGKILL, which the kernel delivers directly and a process cannot catch, ignore, or clean up after; it is terminated immediately, mid-instruction if necessary. SIGKILL is a last resort for a genuinely hung process; reaching for it by default risks corrupted files or orphaned resources that a graceful SIGTERM shutdown would have avoided.
Terraform Troubleshooting Guide: Fix the Errors Engineers Actually Hit
Diagnose Terraform initialization, validation, provider, authentication, state, drift, import, replacement, timeout, and CI failures with a safe workflow.
In a systemd unit, what is the practical difference between Type=simple and Type=forking, and why does that distinction matter for dependency ordering?
With Type=simple, systemd considers the unit started the moment the main process is forked off, it does not wait for the application to finish its own initialization, so anything depending on that unit might start before the service is actually ready to handle requests. Type=forking expects the traditional daemon pattern, the initial process forks and exits once it judges its own startup complete, so systemd marks the unit started as soon as that original process exits successfully, while the actual daemon keeps running as a separate, now-orphaned process. That only tracks the daemonization handoff, not genuine application readiness, a process can exit believing setup is done while it is still finishing initialization in the background, so Type=forking is a better signal than Type=simple but still not a readiness guarantee. Type=notify is the one that actually is readiness-safe: the service explicitly calls sd_notify to tell systemd exactly when it's ready, rather than systemd inferring readiness from process exit behavior at all.
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 the difference between Blob Storage, File Storage, and Disk Storage in Azure?
Blob Storage is object storage for unstructured data (images, backups, logs), accessed via HTTP/HTTPS APIs, not mounted as a filesystem. File Storage provides fully managed file shares accessible via the SMB or NFS protocol, usable as a network drive that multiple VMs can mount simultaneously. Disk Storage provides block-level storage attached to a single VM, functioning as its virtual hard disk. The choice depends on access pattern: Blob for API-driven unstructured data at scale, File for shared network-drive-style access across machines, Disk for a VM's own persistent local-feeling storage.
What is the difference between a role and a policy in most cloud IAM systems?
The word "role" is provider-specific. In AWS, an IAM role is an assumable principal with policies attached. In Azure RBAC and Google Cloud IAM, a role is primarily a reusable collection of permissions; a role assignment or IAM policy binding grants that role to a principal at a scope. Always reduce the model to four questions: which principal, which permissions, on which resource scope, under which conditions. Translating the word "role" literally between providers causes dangerous design mistakes.
What is the practical difference between ps -ef and ps aux, and why do they show different columns for the same processes?
`-ef` is UNIX-style syntax and `aux` is BSD-style syntax for the same underlying command, and they weren't designed as one consistent interface; mixing them can even be ambiguous depending on other options used. The manual is explicit that BSD-style options change the default output to include process state (STAT) and full command arguments (COMMAND) instead of just the executable name, and BSD-style selection also defaults to showing every process the invoking user owns across all terminals, while UNIX-style selection defaults to processes on the current terminal only. Neither is "more correct," they're two different historical option conventions layered onto the same command, which is why picking one and being consistent about it matters more than which one.
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.
Golden Images with Azure Compute Gallery: Hands-On Lab
A step-by-step Azure lab for creating, versioning, and deploying standardized VM images at scale.
If no NetworkPolicy exists in a namespace, what traffic is allowed between pods, and what changes the moment one NetworkPolicy is applied?
With no NetworkPolicy at all, pods are non-isolated: every pod can send and receive traffic from any other pod, with no restriction in either direction. The moment any NetworkPolicy selects a pod for a given direction (ingress or egress), that pod becomes isolated for that direction specifically, and only the traffic explicitly allowed by an applicable policy's rules gets through from then on; unrelated pods elsewhere in the cluster that no policy selects remain fully open. This is why introducing NetworkPolicy incrementally, rather than all at once, tends to break things: the first policy applied to a namespace can silently cut off traffic nobody had previously needed to declare.
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.