Search
30 results for “identity”
Search results
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.
A custom class defines __eq__ based on a value field but leaves __hash__ using default identity-based hashing. What actually goes wrong when you use an instance as a dict key?
In Python 3, simply defining `__eq__` without touching `__hash__` doesn't leave the old identity-based hash in place, Python automatically sets `__hash__` to `None` on that class, making instances unhashable, so using one as a dict key raises `TypeError` immediately rather than corrupting anything. This happens even if a parent class defines `__hash__`: overriding `__eq__` in a subclass sets that subclass's `__hash__` to `None` regardless of what the parent provides, ordinary inheritance does not carry the parent's hash forward. The silent, no-exception version of this bug only happens if the class explicitly keeps or re-supplies an identity-based `__hash__` alongside the value-based `__eq__` (e.g. `__hash__ = object.__hash__`, or, to retain a parent's hash on purpose, `__hash__ = Parent.__hash__`). In that case, two instances with the same value compare equal (`a == b` is `True`) but hash differently, and inserting under key `a` then looking up with an equal-but-distinct key `b` lands in the wrong hash bucket and returns nothing, because the hash mismatch never gave the lookup a chance to even check equality against the right entry.
AWS IAM
How IAM users, roles, and policies control access in AWS, why roles with temporary credentials are preferred over long-lived access keys, and how policy evaluation actually decides allow versus deny.
Azure Active Directory (Entra ID)
How Entra ID identity, app registrations, and role-based access control fit together, and why it governs both human sign-in and workload-to-workload authentication.
What is the difference between an IAM user and an IAM role?
An IAM user is a long-term identity with its own credentials, a password for console access, or access keys for programmatic access, typically representing a human or a legacy application that needs standing access. An IAM role has no long-term credentials of its own; it is assumed, by a user, an application, or an AWS service, and yields short-lived, automatically-expiring temporary credentials via AWS STS. Roles are the preferred identity for anything running on AWS compute (EC2, Lambda, ECS) precisely because there is no long-lived secret to leak or rotate.
How does IAM decide whether a request is allowed, and what wins if there is a conflict between an Allow and a Deny?
IAM evaluation starts from an implicit deny, nothing is allowed unless some applicable policy explicitly allows it. It then checks every applicable policy for an explicit Deny; if one exists anywhere, identity-based, resource-based, a permission boundary, an SCP, or an RCP, the request is denied regardless of how many Allow statements also apply. Beyond that, identity-based and resource-based policies are the only policy types that actually grant permissions, an Allow from either is required. Permission boundaries, SCPs, and RCPs never grant anything themselves, they only cap what a grant can reach, so the request also needs every applicable one of those to independently allow the action; any one of them failing to allow it denies the request even with a valid Allow in place. An explicit Deny always wins over an explicit Allow, no matter which policy or how specific the Allow is.
Why are IAM roles preferred over long-lived access keys for workloads running on EC2 or Lambda?
A long-lived access key is a static secret that must be stored somewhere, an environment variable, a config file, a secrets manager, and rotated manually or via automation; if it leaks, it remains valid until someone notices and revokes it. An IAM role attached to an EC2 instance profile or a Lambda execution role is assumed automatically by the AWS SDK, yielding short-lived credentials that are rotated transparently and expire on their own even if never explicitly revoked. This removes the entire class of "leaked long-lived credential" risk for workloads that run on AWS compute, which is why roles are the default recommendation over access keys whenever the workload runs inside AWS.
What is the difference between Azure RBAC and Entra ID roles?
Entra ID roles (like Global Administrator, User Administrator) control access to Entra ID and Microsoft 365 management functions themselves, managing users, groups, and directory settings. Azure RBAC controls access to Azure resources (VMs, storage accounts, resource groups) via role assignments scoped to a management group, subscription, resource group, or individual resource. They are separate systems that both use Entra ID as the identity provider, a user authenticates once through Entra ID, but what they can then do is governed by two independent role systems depending on whether they're managing identity itself or managing Azure resources.
What is an app registration in Entra ID, and why do workloads need one?
An app registration represents an application's identity in Entra ID, giving it a client ID and the ability to authenticate, either as itself (via a client secret or certificate, for service-to-service calls) or on behalf of a signed-in user (via OAuth 2.0/OpenID Connect flows). Workloads need one because Entra ID authentication and authorization apply uniformly to both humans and applications, a background service calling an API needs its own verifiable identity the same way a person does, and an app registration (often combined with a managed identity to avoid handling secrets directly) is how that identity is established.
Microsoft Entra Conditional Access Explained: MFA, Location Controls, and the What If Tool (Full Lab Guide)
How Conditional Access Evaluates Sign‑Ins Behind the Scenes
How to Install Active Directory Domain Services (AD DS) on Windows Server using Hyper-V (Step-by-Step Guide)
Active Directory Domain Services (AD DS) remains one of the most essential building blocks in enterprise IT. Whether you're managing on‑prem infrastructure, hybrid cloud environments, or lab setups, understanding how to deploy and configure AD DS is a core skill for any cloud infrastructure or syst…
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.
Linux Users, Groups & sudo
How /etc/passwd and /etc/shadow split identity from password storage, why a UID (not a username) is what the kernel actually checks, and how a sudoers rule's who/where/as-whom/what structure grants privileges.
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.
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 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 is the difference between a role and a policy in most cloud IAM systems?
A policy is a document that defines a set of permissions, which actions are allowed or denied on which resources, sometimes under which conditions. A role is an identity that policies get attached to, and which something (a user, or more commonly a workload like a compute instance or function) can assume to gain those permissions temporarily. The distinction matters operationally: policies are the reusable permission logic, while roles are how that logic gets bound to something that actually makes requests, separating "what is allowed" from "who currently has it."
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.
What does journalctl -u myservice actually show you, beyond just log lines the service itself printed?
`-u`/`--unit=` expands into a filter that captures more than the service's own stdout/stderr, it includes messages logged about the unit by systemd itself (start, stop, failure notifications) and associated coredump information if the process crashed, correlated by the unit's identity rather than by manually grepping a shared log file for its name. This is more reliable than text-searching a combined log, since it's scoped by the actual unit metadata the journal records, not by whatever string happens to appear in a log line.
What is a "golden path" and why does it matter more than giving teams unlimited flexibility?
A golden path is an opinionated, well-supported, self-service way to accomplish a common task, spinning up a new service, provisioning a database, setting up a CI pipeline, that comes with sane defaults for security, observability, and reliability already wired in. Unlimited flexibility sounds appealing but means every team re-solves the same problems (how do we get logs flowing, how do we handle secrets) slightly differently, multiplying the platform team's support burden and creating inconsistent security/reliability posture across the organization. A golden path trades some flexibility for consistency and speed, while still allowing teams to go off-path when they have a genuine reason to.
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.
PostgreSQL's documentation says it's "impossible to suppress nested-loop joins entirely" even with enable_nestloop off. What does that tell you about relying on planner hints to force a specific join algorithm?
That specific guarantee is documented only for `enable_nestloop`: turning it off only discourages the planner by making nested loops look artificially expensive in cost estimation, it can't hard-disable them, because for some queries a nested loop is the only viable plan at all (for example, certain correlated subquery shapes), so the planner will still use one if it must. `enable_hashjoin` and `enable_mergejoin` don't carry that same caveat, disabling either one actually can prevent the planner from choosing that join type, since a nested loop (or the other remaining method) is always available as a fallback plan. In practice, though, all three settings are best treated as a debugging/diagnostic tool for understanding planner behavior, not a reliable production mechanism for forcing a specific join algorithm, the actual fix for a bad plan is almost always better statistics (via `ANALYZE`) or a better index, not overriding the planner's method choice.
AWS Cloud Engineer Roadmap
From the AWS account structure through identity, networking, compute, storage, and monitoring, the core path for a working AWS engineer, linked into Cloud Tech by Victor topic references.
Azure Engineer Roadmap
From the Azure resource hierarchy through identity, networking, compute, storage, and monitoring, the core path for a working Azure engineer, linked into Cloud Tech by Victor topic references.
Cloud Engineer Roadmap
Vendor-agnostic cloud fundamentals, service models, identity, networking, through to provisioning, orchestration, and cost management, linked into Cloud Tech by Victor topic references.
DevSecOps Engineer Roadmap
From least-privilege identity and secrets management through a hardened CI/CD pipeline, container and Kubernetes security, and policy-as-code for infrastructure, the core path for shifting security left, linked into Cloud Tech by Victor topic references.
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.
A consumer receives a message, starts processing, but crashes before deleting it. What happens to that message, and why is this actually the desired behavior?
Once the visibility timeout expires without the message being deleted, it automatically becomes visible again in the queue and can be picked up by the same or a different consumer for another processing attempt. This is deliberate, not a bug: the alternative (a crashed consumer's message vanishing permanently) would silently lose data, whereas reappearing after timeout guarantees eventual processing at the cost of a possible duplicate attempt, which is exactly the trade-off "at-least-once delivery" describes. Setting the visibility timeout too short causes premature, unnecessary reprocessing of messages still legitimately being worked on; too long delays legitimate retries after a real crash.
Why is the CAP theorem often described as "choose two of three," and why is that framing slightly misleading?
The framing suggests a system designer picks any two of consistency, availability, and partition tolerance as a free, standing choice, but partition tolerance isn't actually optional for a real distributed system, network partitions happen (a link fails, a node becomes unreachable), so a system that "chooses" not to tolerate partitions simply isn't distributed in any meaningful sense once one occurs. The real choice CAP describes is narrower and only activates during an actual partition: when nodes can't communicate, do you keep responding and risk inconsistency (AP), or do you pause and refuse some requests to guarantee consistency (CP)? Outside of an actual partition, a well-designed system can be both consistent and available; CAP is a statement about what happens specifically during a partition, not a permanent, constant trade-off.
What is the difference between a security group and a network ACL in a VPC?
A security group is stateful and attaches at the instance/ENI level: it only supports allow rules, and if inbound traffic is allowed, the corresponding response traffic is automatically allowed back out regardless of outbound rules. A network ACL is stateless and attaches at the subnet level: it supports both explicit allow and explicit deny rules, numbered and evaluated in order starting from the lowest number, and because it has no memory of prior traffic, allowing inbound traffic does not automatically allow the matching outbound response, that has to be permitted by its own rule. Security groups are the primary, fine-grained access control per resource; network ACLs are a coarser, optional second layer at the subnet boundary.