Search
30 results for “sas”
Search results
Securing Azure Blob Storage: Network Rules, SAS, Immutability
A hands-on lab automating secure Azure Blob Storage using VNets, subnets, SAS tokens, and immutability.
Terraform State Management: Remote, Secure, and Recoverable
Design secure remote Terraform state with locking, encryption, least privilege, version recovery, AzureRM and S3 patterns, migration, and restore drills.
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).
Terraform Apply Stuck Acquiring State Lock
A safe Terraform state lock troubleshooting guide for stuck apply runs, stale locks, lock IDs, force-unlock, backend behavior, and CI pipeline guardrails.
Linux Security and Hardening: SSH, Firewalls, Permissions
How Linux Protects Itself and How Administrators Make It Safer.
How to Set Up a Secure Point-to-Site VPN in Azure
A Hands-On Azure Networking Lab: Virtual Networks, VPN Gateway, and Certificate Authentication.
What is a Service Control Policy (SCP), and what is the one thing it does not do?
An SCP is a policy attached to an AWS Organizations root, organizational unit, or member account that defines the maximum available permissions for every identity in that account, including that account's own administrators and its root user. What an SCP does not do is grant any permission by itself, it only sets a ceiling; an identity still needs an actual IAM allow (from an identity-based or resource-based policy) within that ceiling to do anything. An SCP with no matching IAM allow underneath it results in access denied, not access granted, which is the most common misunderstanding of how SCPs work. One exception worth knowing: SCPs never apply to the organization's management account itself, only to member accounts.
How do access tiers (Hot, Cool, Archive) affect Blob Storage, and what do they not affect?
Access tiers change the cost trade-off between storage price and access/retrieval price: Hot has the highest storage cost but cheapest, immediate access; Cool has lower storage cost but a higher per-access cost and is meant for infrequently accessed data; Archive has the lowest storage cost but data must be rehydrated (a process taking hours) before it can be read at all. What tiers do not affect is durability, the redundancy option (LRS/ZRS/GRS) determines durability independently of which access tier a blob is in, so a Cool or Archive blob is exactly as durable as a Hot one with the same redundancy setting.
What makes a subnet "public" versus "private" in a cloud VPC?
It is entirely determined by routing, not by any label or flag on the subnet itself. A subnet is "public" if its route table sends traffic destined for the internet (0.0.0.0/0) to an internet gateway. A subnet is "private" if that route instead points to a NAT gateway (for outbound-only internet access) or has no internet route at all. Two subnets can be configured identically in every other respect and differ only in that one route table entry, which is why auditing actual route tables matters more than trusting subnet names like "public-subnet-1."
What is the difference between a security group and a network ACL?
A security group is stateful and attached to individual resources (like an instance or load balancer), if you allow inbound traffic on a port, the corresponding outbound response is automatically allowed, and rules are evaluated as an allow-list only. A network ACL is stateless and attached to a subnet, evaluating both inbound and outbound rules independently for every packet, including explicit deny rules. Security groups are the primary, more commonly used tool for per-resource access control; network ACLs add a coarser, subnet-wide layer, often left at their permissive default and used mainly for defense-in-depth or to explicitly block something.
What is the difference between `git reset` and `git revert`, and when should you use each?
git reset moves the current branch pointer (and optionally the staging area and working directory) to a different commit, effectively rewriting history as if the reset-past commits never happened on this branch - fine for commits that only exist locally and haven't been pushed. git revert creates a brand new commit that applies the inverse of a previous commit's changes, leaving history intact and additive. Because it doesn't rewrite anything, revert is the safe choice for undoing a commit that's already been pushed and pulled by others; reset --hard on shared history causes exactly the same divergence problem as a rebase on a shared branch.
What is the difference between a Pod, a Deployment, and a Service?
A Pod is the smallest deployable unit, one or more containers that share network and storage, scheduled together onto a node. Pods are ephemeral and disposable; Kubernetes recreates them freely and their IPs change every time. A Deployment manages a set of identical Pods (a ReplicaSet under the hood), handling rolling updates, rollbacks, and keeping the desired replica count running even as individual Pods die. A Service gives that changing set of Pods a stable network identity, a fixed virtual IP and DNS name, so other things in the cluster don't need to track individual Pod IPs, which change constantly.
Why can't you rely on a Pod's IP address for service discovery?
Pods are ephemeral by design, Kubernetes kills and recreates them constantly (failed health checks, node drains, rolling deployments, autoscaling), and every new Pod gets a brand-new IP address. Hardcoding or caching a Pod IP breaks the moment that Pod is replaced. A Service solves this by providing a stable virtual IP and DNS name that always routes to whichever Pods currently match its label selector, regardless of how many times the underlying Pods have been replaced.
How would you troubleshoot a Service that exists but returns no response?
Work from the application outward: confirm the selected Pods are Ready and serving on the expected container port, compare the Service selector with Pod labels, inspect EndpointSlices to verify Kubernetes discovered backends, confirm port and targetPort, then test Service DNS and IP from inside the cluster. An empty EndpointSlice usually points to a selector/readiness mismatch; healthy endpoints with failed DNS or routing move the investigation to cluster networking.
Why does sending SIGKILL to a stuck process work when SIGTERM doesn't, and what does that cost you?
SIGTERM asks a process to terminate but can be caught by a signal handler, letting the process run its own cleanup logic (closing files, flushing buffers, releasing locks) before actually exiting, or in a broken process, being caught and never acted on at all. SIGKILL cannot be caught, blocked, or ignored under any circumstances, the kernel terminates the process directly, which is why it works on a process SIGTERM couldn't reach. The cost is that none of that cleanup logic runs, a database connection isn't closed cleanly, a temp file isn't removed, a lock isn't released, so SIGKILL is a last resort after SIGTERM has been given a real chance to work, not a default first move.
Why Every Container in Your Rolling Deploy Takes an Extra 10 Seconds to Stop
Why npm as PID 1 can prevent Node.js from receiving SIGTERM, trigger Docker's ten-second timeout, and end container shutdown with SIGKILL.
Linux Processes and Networking: Signals, Ports, Monitoring
How Linux Runs, Communicates, and Stays Alive.
Secure Azure Environment with Bicep and Private Endpoints
A hands-on Infrastructure-as-Code lab deploying a production-ready Azure environment from a single Bicep template.
Azure Deployment Slots: Zero-Downtime Web App Deployments
A practical Azure App Service lab covering staging slots, slot swaps, autoscaling, and traffic testing.
Scalable Hyper-V Storage with iSCSI, VHDs, and Storage Pools
Virtual Disks, Storage Pools, and iSCSI - The Hidden Challenges of Hyper-V Storage (And How I Solved Them)
Cloud Computing Explained: Models, Architecture, and Security
What cloud computing actually is: service and deployment models, core architecture, security, and how platforms like Azure fit real workloads.
Infrastructure as Code Security
How plan-stage policy blocks unsafe AWS and Azure infrastructure before deployment, with practical policy testing and enforcement guidance.
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.
df Says Your Disk Is Full. du Says It Isn't. Both Are Right.
Learn why deleted-but-open Linux files stay on disk, how to find them with lsof +L1, reclaim the space safely, and prevent repeat incidents.
Linux Process Management & systemd
Why SIGKILL cannot be caught the way SIGTERM can, and how systemd's Type= decides when a service actually counts as started.
Why would an organization use multiple AWS accounts instead of one account holding all resources?
Separate accounts per environment (production, staging, development) or per team give a hard isolation boundary that a single account with tags or naming conventions cannot: a mistake or compromised credential in a development account cannot reach production resources at all, rather than merely being restricted by IAM policy within the same account. It also gives cleaner cost attribution (billing rolls up per account), independent service quotas, and a natural blast-radius limit for security incidents. AWS Organizations, and patterns built on top of it like a landing zone, exist specifically to make many accounts manageable, centralized billing, centralized logging, and org-wide SCPs, without losing that isolation.
What is the difference between a resource group and a subscription in Azure?
A subscription is a billing and access-management boundary; it's tied to an agreement with Microsoft, has its own spending limits and quotas, and is typically the unit organizations use to separate environments (production vs. non-production) or business units. A resource group is a logical container inside a subscription that groups related resources (a VM, its disks, its network interface) that share the same lifecycle, created and deleted together. Deleting a resource group deletes everything in it, which makes resource groups the practical unit of "this is one deployable thing," while subscriptions are the practical unit of "this is one billing and governance boundary."
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.
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 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.