Search
30 results for “iam”
Search results
Cloud IAM Fundamentals
How identities, roles, policies, scopes, and temporary credentials map across AWS, Azure, and Google Cloud, with practical access troubleshooting.
What is the difference between authentication and authorization in a cloud IAM context?
Authentication answers "who is making this request", verifying an identity via credentials, a token, or a federated login. Authorization answers "is this identity allowed to do this specific action on this specific resource", evaluated after authentication succeeds, by checking the identity's attached policies against the requested action. A request can be perfectly authenticated (the caller genuinely is who they claim) and still be denied, because authorization is a separate check against what that identity is actually permitted to do.
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.
AWS Fundamentals
How AWS accounts, regions, identity, and core services fit together, with a practical CLI and access-denied troubleshooting workflow.
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 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.
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 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.
Automating Azure Infrastructure with Bicep: Hands-On IaC Lab
Deploying VNets, VMs, IAM, Policies, Monitoring, and Governance using Infrastructure as Code.
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.
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 a Docker image and a Docker container?
An image is a read-only, layered filesystem snapshot plus metadata (entrypoint, exposed ports, environment); it never changes once built and can be shared through a registry. A container is a running (or stopped) instance of an image: Docker adds a thin writable layer on top of the image's read-only layers and starts a process inside an isolated namespace. You can start many independent containers from the same image, each with its own writable layer and state, the same way many processes can run from the same binary on a normal OS.
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 practical difference between `git merge` and `git rebase`?
Both bring one branch's commits into another, but they produce different history shapes. `git merge` creates a new merge commit with two parents, preserving exactly how the branches diverged and came back together; nothing is rewritten, which is why merge is safe on shared/public branches. `git rebase` replays your branch's commits one by one on top of the target branch's tip, producing a linear history with no merge commit, but every replayed commit gets a new hash. That rewriting is why rebase should be avoided on branches other people have already pulled; their history and yours will diverge as soon as they fetch the rewritten commits.
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.
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.
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 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.
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 metric cardinality, and why can it break a monitoring system?
Cardinality is the number of unique label/tag combinations a metric can have. A metric like `http_requests_total{user_id=...}` has cardinality equal to the number of distinct users, potentially millions, because most metrics backends store a separate time series per unique label combination. High-cardinality labels cause a combinatorial explosion in stored time series, which can degrade or crash a metrics backend entirely. The fix is keeping metric labels low-cardinality (route, status code, method) and pushing genuinely high-cardinality data (user IDs, request IDs) into logs or traces instead, where it belongs.
Linux Processes and Networking: Signals, Ports, Monitoring
How Linux Runs, Communicates, and Stays Alive.
Automating Active Directory User and Group Management with PowerShell
Step-by-step lab: creating users, OUs, security groups, and group memberships using PowerShell
NTFS Permissions and Mapped Drives in a Windows Domain
Design secure domain file sharing with NTFS permissions, group-based access control, and mapped drives on Windows Server 2019.
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 does data written inside a container disappear when the container is removed?
Anything a container writes lands in its own writable layer, which is deleted along with the container by `docker rm`. That is deliberate; it is what makes containers disposable and reproducible, a fresh container from the same image always starts from the same known state. Anything that actually needs to survive a container's lifecycle (a database's data files, uploaded assets) has to live outside that writable layer, in a named volume or a bind mount, which Docker mounts into the container at a chosen path but manages independently of the container itself.
What is the difference between the working directory, the staging area, and a commit in Git?
The working directory is the actual files on disk, whatever state you've left them in. The staging area (the "index") is a snapshot of exactly what will go into the next commit; `git add` copies changes from the working directory into it, one file or hunk at a time, which is why you can commit only part of what you've changed. A commit is a permanent, immutable snapshot of the staging area at the moment you ran `git commit`, plus a pointer to its parent commit, which is what forms the project's history graph. Understanding that staging is a separate, explicit step - not just "what's changed" - explains why `git status` shows both staged and unstaged changes for the same file.
Why does GitOps improve auditability compared to engineers running kubectl or terraform apply directly?
Every change to cluster state has to go through a Git commit, which means it inherits Git's existing history, authorship, and (if branch protection is configured) pull-request review, automatically. Direct `kubectl apply` access leaves no equivalent trail: two changes with the same effect are indistinguishable, there's no required review step, and reconstructing "who changed what and why" after an incident means digging through cluster event logs instead of reading a linear, reviewed commit history.
Why is scanning IaC source (Terraform files) not sufficient on its own, without also checking the plan?
Static scanning can catch hardcoded insecure defaults but cannot see the complete result of runtime inputs, data sources, and module composition. A Terraform plan is the best prediction of the concrete resource changes Terraform is about to make, so plan policy sees substantially more than source scanning. It is not guaranteed to know every value before apply, however; security-sensitive unknown values need an explicit fail-closed or exception rule rather than being assumed safe.
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.
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.