Identity and Access Management Architecture Questions

Design and evaluate architectures that provide authentication and authorization across users, services, and systems in enterprise environments. Coverage includes the identity lifecycle and provisioning, directory services and identity federation, single sign on and federation protocols such as Security Assertion Markup Language and OpenID Connect, multi factor authentication and passwordless authentication, privileged access management, service account and machine identity handling, and onboarding and offboarding workflows. Candidates should be able to design token issuance and lifecycle, secret and key management, service to service authentication patterns, session and credential rotation, and scalable authorization strategies for distributed systems and microservices. Policy and control topics include role based access control, attribute based access control, resource based policies, permission boundaries, separation of duties, policy decision point and policy enforcement point placement, and modeling for least privilege and role assumption flows. Operational concerns include high availability, scalability, performance tradeoffs, observability and monitoring of identity services, audit logging, access review and attestation processes, access request and approval workflows, emergency or break glass access processes, and testing and validation to prevent privilege escalation. The description also covers integration patterns with enterprise identity providers and cloud account models, balancing security with user experience, and compliance and regulatory considerations.

HardTechnical

48 practiced

Design least-privilege controls for CI/CD pipelines: how to provision ephemeral credentials to runners, minimize secrets exposure, apply fine-grained authorization to artifact registries and cloud APIs, enforce principle of least privilege in pipeline steps, and provide audit trails of pipeline access to production systems.

Sample Answer

**Clarify goals & constraints**- Protect CI/CD secrets, ensure ephemeral access, enforce least privilege per pipeline step, secure artifact and cloud API access, and provide auditable trails without blocking developer velocity.

**Design overview**- Short-lived credential broker + OIDC-based auth for runners- Step-scoped service identities with role-restricted cloud/IAM roles- Artifact registry ACLs per pipeline/job- Secrets-zero approach in repos; secrets injected at runtime via vault- Comprehensive telemetry and immutable audit logs

**Components & controls**- Identity: Use OIDC (GitHub Actions, GitLab, GCP/Azure OIDC) so runners exchange workload tokens for short-lived cloud credentials; avoid static keys.- Broker: Deploy a Vault-like broker (HashiCorp Vault with Kubernetes auth or cloud KMS+STS) issuing ephemeral secrets/TLS certs with TTLs, lease revocation, and auto-rotation.- Fine-grained roles: Create least-privilege roles per job type (build/publish/deploy). Map pipeline jobs to minimal IAM policies (e.g., only push to specific artifact repo path, only read specific secrets).- Artifact access: Use scoped repo tokens or artifact-role bindings; enforce signed images/artifacts (cosign) and attestations (in-toto/SLSA).- Secrets handling: Never store secrets in pipeline YAML. Use transit encryption in Vault; inject secrets into ephemeral in-memory filesystem or ephemeral sidecar; wipe after step.- Network & runtime: Enforce network egress controls, private registries, and ephemeral runner sandboxes. Use ephemeral containers/VMs destroyed post-run.- Authorization: Enforce approval gates and break-glass with short-lived elevated roles requiring multi-person approval.- Auditing: Centralize logs (immutable SIEM/Cloud Audit Logs) capturing token issuance, Vault access, role assumption, artifact pushes, commit SHA, job ID, and runner hostname. Ensure logs are tamper-evident (WORM, signed).- Automation & policy: Implement OPA/Gatekeeper checks to validate pipeline manifests for disallowed permissions; fail CI on policy violations.- Testing & validation: Regularly run CI fuzz tests and red-team the pipeline to ensure no secrets leakage and role misconfigurations.

**Why this works**- OIDC + broker eliminates long-lived credentials.- Role scoping + per-step identities minimizes blast radius.- Runtime injection and ephemeral runners reduce exposure window.- Strong audit trail enables post-incident forensics and policy enforcement.

**Example policy snippet (conceptual)**- Build job role: allow artifact:write on repo "org/package/build-artifacts/*", deny all cloud-admin actions.- Deploy job role: allow runtime:invoke on prod-services with approval tag, allow image:pull from signed-images only.

This design balances security with developer productivity while enforcing principle of least privilege end-to-end.

HardTechnical

64 practiced

An application accepts social identity federation (Google, Facebook) and you suspect credential stuffing and account takeovers via a weak external IdP. Design defenses at the federation level to mitigate abuse while preserving user experience: consider identity assurance levels, attribute validation, risk-based authentication, conditional MFA, throttling, and alternative verification flows.

Sample Answer

**Clarify goal & constraints**Protect users from credential stuffing/account takeover via weak external IdPs while keeping social login smooth. Assume we can consume IdP claims, risk signals (token age, issuer), and user device/behavior telemetry.

**Design overview**- Identity assurance levels (IAL): map federated logins to IAL0–IAL2. - IAL0: minimal (just ephemeral session) - IAL1: basic profile verified (email claim from trusted IdP, recent OIDC token) - IAL2: high-assurance (secondary verification, verified phone or government ID)- Attribute validation: - Validate id_token signature, issuer, audience, token age, nonce. - Normalize and verify email_verified, phone_verified claims. Reject or flag missing/false. - Cross-check federated email against stored account history (previous IdP, signup age).- Risk-based authentication (RBA): - Build real-time risk score from device fingerprint, IP reputation, geolocation delta, token characteristics, velocity (failed attempts), and known bot signals. - Use ML/heuristics; weights for sudden geolocation, new device, low token entropy.- Conditional MFA: - For medium risk: step-up to OTP or one-tap MFA (push) tied to a registered device. - For high risk or IAL2-required actions: require MFA + rebind phone or hardware key (FIDO2).- Throttling & abuse throttles: - Per-IP and per-IdP clientID login rate limits, progressive delays after failures, global CIDR backoffs. - Detect credential stuffing patterns (many accounts from same IP range, same password hashes) and block/blacklist.- Alternative verification flows: - If IdP is weak (low assurance or flagged), allow blended verification: federated login + email challenge, or federated login limited to read-only until user completes phone verification or FIDO enrollment. - Offer account recovery via existing verified contact only; require additional verification for account linking.- Operational controls & feedback: - Monitor false-positive/negative rates, ATO incidents, conversion impact; tune thresholds. - Share signals back to IdP when possible (abuse reports), and maintain allow/blocklists per IdP client. - Audit trails for federation mappings and step-ups.

**Example rule set**- If token_age > 5m and email_verified=false → block.- If risk_score > 0.8 → require FIDO2 or deny.- If same IP attempts > 50 accounts in 10m → throttle and captcha.

This balances UX by allowing low-risk, trusted social flows while stepping up or limiting capability under detectable risk, with measurable telemetry and continuous tuning.

MediumTechnical

54 practiced

Describe proactive and reactive methods to detect and prevent privilege escalation across accounts and services. Include design-time strategies (least privilege, separation of duties, permission boundaries), runtime detection signals, monitoring heuristics, automated guardrails, and testing approaches such as red-teaming and entitlement scanning.

Sample Answer

**Overview (voice of a Cybersecurity Engineer)** I implement layered proactive and reactive controls so privilege escalation is blocked at design-time and detected at runtime.

**Design-time (preventive)** - Apply least privilege: role-by-role access matrices, just-in-time (JIT) elevation, scoped short-lived creds (STS). - Separation of duties: enforce via role design and approval workflows for sensitive actions (e.g., deploy vs approve). - Permission boundaries: resource-scoped policies, attribute-based access control (ABAC) tags (env, owner), resource quotas to limit lateral move. - Automation: CI checks that IaC templates fail build if wide perms (e.g., "*" or owner) detected.

**Runtime detection signals & heuristics (reactive)** - Unusual token usage: long-lived token used after rotation window, cross-region/session anomalies. - Privilege spike: sudden invocation of admin APIs by low-privilege identity. - Lateral movement patterns: access to new service combinations, uncharacteristic network flows. - Impossible travel, anomalous geolocation, increased error/success ratio for privilege-change APIs.

**Monitoring & automated guardrails** - Central telemetry: log aggregation (auth, audit, API calls), enrich with identity context. - Real-time rules: SIEM/EDR detections for privilege-elevation API calls, adaptive risk scoring. - Automated response: revoke sessions, rotate keys, block offending role, notify owners, open ticket. - Preventive guards: IAM permission boundaries enforced by policy engine, service control policies for cloud orgs.

**Testing & validation** - Entitlement scanning: continuous RBAC/IAM inventory, detect orphaned/admin-capable accounts, privilege drift alerts. - Red-team/blue-team: routine escalation emulation (credential theft, role chaining), verify detections and playbooks. - Chaos/Canary tests: intentionally trigger JIT/failover to validate least-privilege holds. - Metrics: time-to-detect, mean-time-to-contain, number of excessive entitlements reduced.

I prioritize automation and measurable controls so prevention reduces blast radius and detection closes gaps quickly.

HardSystem Design

48 practiced

Design a migration plan to move from a coarse-grained RBAC model (role-per-team) to fine-grained ABAC in a large organization with minimal disruption. Cover attribute sourcing and trustworthiness, policy authoring and testing, enforcement strategies, pilot phases, rollback procedures, metrics to validate correctness, and how to handle legacy apps that cannot accept ABAC attributes.

Sample Answer

**Overview / goals**Migrate from role-per-team RBAC to fine-grained ABAC with minimal disruption, preserving safety, auditability, and rollback capability while incrementally increasing enforcement.

**Clarify architecture & components**- Deploy PDP (policy decision point: OPA/Envoy authz), PEP (enforcement: service mesh, API gateway, sidecars), PIP (attribute provider: IdP, HR DB, CMDB, AD, device telemetry), PAP (policy authoring UI/Git repo).- Use JWT/SAML with signed attribute assertions and mTLS for trust.

**Attribute sourcing & trustworthiness**- Authoritative sources: HR system (title, manager), IdP (group, 2FA status), CMDB (env, app owner), MDM (device posture).- Enforce provenance: attributes signed by source, include source_id and timestamp, TTLs, and revocation checks.- Normalize via an attribute normalization service (SCIM pipeline) with validation rules and confidence score per attribute.

**Policy authoring & testing**- Store policies in Git (policy-as-code). Use OPA/Rego or XACML; apply unit tests, property-based tests, and a synthetic data harness.- Automated CI: validate policies against canonical scenarios, run fuzz tests and negative tests, perform SAT-based conflict detection.- Peer review + policy change approvals via workflow (Git PRs, auto-tests).

**Enforcement strategy & rollout**- Phased enforcement: Observe -> Enforce-with-warnings -> Enforce. - Phase 0: Decision logging only (PEP queries PDP, no enforcement). - Phase 1: Soft deny: deny but allow via just-in-time bypass with audit. - Phase 2: Strict enforce.- Start with low-risk services, then expand by business unit.

**Pilot phases & rollout plan**- Pilot one domain (e.g., internal docs) for 4–8 weeks: collect logs, fix attribute gaps, refine policies.- Canary per cluster/service (5–10% users), progressively increase.- Maintain hybrid mode: RBAC continues as fallback; map roles to attributes and introduce attribute-based mappings.

**Rollback & fault tolerance**- Feature flags at PEP for immediate disable (revert to RBAC logic).- Timeouts: if PDP unavailable, default to safe-mode (deny or RBAC fallback depending on SLA).- Maintain audit trail of policy versions; quick redeploy via CI pipeline.

**Metrics to validate correctness**- Decision accuracy: compare ABAC decision vs legacy RBAC on historical traces.- False positives/negatives rate (blocked legitimate vs allowed illegitimate).- Authorization latency (p50/p95/p99).- Policy coverage: percent requests decisioned by ABAC vs RBAC.- Attribute freshness and provenance failures.- User impact: helpdesk tickets, access escalation requests.

**Handling legacy apps**- For apps that can’t consume attributes: - API gateway / sidecar injects translated RBAC tokens: PDP evaluates attributes and issues short-lived RBAC tokens (token translation). - Authz proxy in front of app enforces decisions. - Use an ABAC façade service that returns allow/deny and logs decisions.- Long term: plan refactor or wrap legacy apps to accept standard tokens (JWT with claims).

**Governance & ops**- Design SLA for PDP availability, scale with caching and local decision caches.- Continuous monitoring: alert on attribute source anomalies, decision drift, spike in denials.- Training for app teams; runbooks for incidents.

Example: map "manager_of(resource.owner)" attribute by combining HR manager id + resource owner from CMDB; sign and cache with 60s TTL, test with unit tests and canary before enforcing.

This plan preserves safety (fallback/RBAC), builds trusted attributes, uses policy-as-code and automated testing, and provides clear rollback and metrics for iterative, low-risk migration.

EasyTechnical

53 practiced

What are machine identities and service accounts? Describe best practices for managing them including short-lived credentials, certificate-based authentication, workload identity (e.g., cloud provider identity or SPIFFE), least privilege, rotation automation, and how to detect orphaned or unused service accounts.

Unlock Full Question Bank

Get access to hundreds of Identity and Access Management Architecture interview questions and detailed answers.

Join thousands of developers preparing for their dream job.