Google Entry-Level Security Architect Interview Preparation Guide

Direct answer

Onboarding an acquired company's cloud accounts and data stores is a four-phase sequence, assess, isolate and ingest, sanitize and validate, then align identity, and the ordering is deliberate: you cannot safely transfer data before assessing what state it is actually in, and you should not connect the acquired environment's identities to your own governance model until the data flowing through that connection has already been validated as safe.

Structured elaboration

Phase 1: assess security posture. Inventory the acquired company's cloud accounts, identity and access management (IAM) principals, data stores, and network exposure before touching anything; specifically look for the misconfiguration patterns most likely in an environment that has not been held to your own governance standard (public storage, overly broad IAM roles, missing encryption, unpatched compute). This assessment produces a risk list that directly shapes how cautious the next three phases need to be, an environment with a clean assessment can move faster than one with several open findings.

Phase 2: isolate, then transfer data safely. Before any data moves, the acquired environment should be network-isolated from your own production environment, connected only through a narrow, purpose-built, one-way ingestion path, not a broad peering or shared-account relationship; this is the same "isolate first, integrate deliberately" principle used in any multi-account onboarding. Data transfer itself uses an encrypted, authenticated channel with integrity verification (checksums or a similar mechanism) confirming what arrived matches what was sent, landing first in a staging location in your own environment that downstream systems do not yet trust or query.

Phase 3: sanitize personally identifiable information (PII) where required. Before data moves from the isolated staging location into your production data stores, classify it against your own data-handling policy, and apply masking, tokenization, or removal to any field that does not meet your organization's retention or handling justification for the data's new context (a legitimate need in the acquired company's original product may not carry over to how your organization intends to use the same data). This step happens specifically before production ingestion, not after, since data already merged into production is materially harder to retroactively sanitize without missing a copy.

Phase 4: align identity and access controls. Only after the data path has been validated as safe do you begin migrating the acquired environment's identities into your own governance model: map their IAM principals to your own role structure, retire any credential or access pattern that does not meet your standard (a shared service account, a long-lived static key), and bring their accounts under your organization's multi-account structure (your logging, your guardrails, your Service Control Policies) rather than leaving them as a permanently separate, differently-governed environment.

Worked example

A data engineer onboarding an acquired analytics company's cloud accounts finds, during Phase 1 assessment, that customer usage data is held in an S3 bucket with public-read enabled (a legacy misconfiguration from before the acquisition) and that the acquired company's application servers run under a single, broad IAM role shared across every service. This elevates the caution level for the following phases: Phase 2's transfer path is designed so the actively-public bucket's contents are the first priority for isolation, moved into a private, access-controlled staging location before anything else, since the assessment already flagged it as an active exposure, not a theoretical one. During Phase 3, the engineer discovers the acquired dataset includes a customer email field that the acquiring company's own data-handling policy requires to be tokenized before entering any production system the wider organization can query; that tokenization happens in staging, before the Phase 4 identity migration ever grants broader internal access to this dataset. Only once both the exposure is closed and the sanitization is complete does Phase 4 begin, retiring the acquired company's shared broad IAM role in favor of per-service roles matching the acquiring organization's own least-privilege standard.

Trade-offs and pitfalls

• Rushing to Phase 4 (identity alignment) before Phases 2 and 3 are complete is the most consequential ordering mistake, because it grants your own organization's broader internal access to data that has not yet been assessed or sanitized, effectively widening the audience for a still-unvalidated dataset rather than narrowing it first; the four-phase order exists specifically to avoid this.
• The assessment in Phase 1 needs to be genuinely thorough, not a formality, since its findings directly determine how cautious the rest of the process needs to be; an acquisition under business pressure to integrate quickly can create pressure to abbreviate this phase, which is exactly the wrong place to cut time given how much the following phases depend on its output.
• Sanitization decisions in Phase 3 require a real data-classification judgment call, not a mechanical checklist, since the acquired company's original justification for holding certain data may or may not carry over to your organization's own use case; this needs input from whoever owns data-handling policy, not a decision the data engineer makes unilaterally.
• A "temporary" exception to keep the acquired environment on its own separate identity model past the planned Phase 4 timeline is a common drift point, since business pressure to show integration progress can create incentive to declare onboarding "done" once data is flowing, even if identity alignment remains incomplete; an incomplete Phase 4 means the acquired environment continues operating under a different, potentially weaker governance standard indefinitely.

Approach (brief)
Group hosts by their tags from CSV, produce JSON policy with groups as source/destination, and allow rules for predefined service ports. Ensure idempotency by using deterministic IDs (hashes) and merging existing policy file if present.

Sample Python (idempotent)

#!/usr/bin/env python3
import csv, json, hashlib, os

PORTS = [{"name":"ssh","port":22},{"name":"http","port":80},{"name":"https","port":443}]
POLICY_FILE = "microseg_policy.json"

def id_for(name):
    return hashlib.sha1(name.encode()).hexdigest()[:8]

def load_inventory(path):
    tags = {}
    with open(path) as f:
        reader = csv.DictReader(f)
        for r in reader:
            for t in r['tags'].split(';'):
                tags.setdefault(t.strip(), []).append({"hostname":r['hostname'],"ip":r['ip']})
    return tags

def build_policy(groups):
    policy = {"groups":[], "rules":[]}
    for gname, hosts in sorted(groups.items()):
        policy['groups'].append({"id": id_for(gname), "name": gname, "members": [h['ip'] for h in hosts]})
    for src in policy['groups']:
        for dst in policy['groups']:
            if src['id']==dst['id']: continue
            for p in PORTS:
                rid = id_for(src['id']+dst['id']+p['name'])
                policy['rules'].append({"id":rid,"src":src['id'],"dst":dst['id'],"port":p['port'],"protocol":"tcp","action":"allow"})
    return policy

inv = load_inventory("assets.csv")
new = build_policy(inv)

# idempotent write/merge: if file exists, only replace rules/groups when changed
if os.path.exists(POLICY_FILE):
    with open(POLICY_FILE) as f: old = json.load(f)
else:
    old = {}
if old != new:
    with open(POLICY_FILE,'w') as f: json.dump(new,f,indent=2)
    print("Policy updated")
else:
    print("No changes")

Idempotency reasoning
Deterministic IDs and sorted iteration guarantee same output for same input; merge/compare avoids unnecessary writes.

Staging tests before enforcement

• Run script in staging with realistic CSV; verify JSON diff against expected (git, unit tests).
• Deploy read-only into policy engine (simulation mode) to validate no unintended denies.
• Run connectivity tests (nmap, service checks) from representative VMs to ensure allowed flows work and others remain blocked in a non-production sandbox.
• Peer review and run automated CI checks that validate ID stability and schema.

Clarify requirements & constraints

• Enterprise hybrid (cloud + on‑prem), must provide JIT/JEA, approval workflows, time‑limited elevation, session recording, break‑glass, full audit, automated deprovisioning, minimal user friction, integrate with existing IGA/PAM/SSO and SIEM.

High‑level architecture

• Identity plane: SSO + Conditional Access, IGA (identity lifecycle)
• Control plane: Privileged Access Service (PAM/JIT broker) with workflow engine
• Enforcement plane: Cloud CASB/Cloud-native IAM APIs, on‑prem PAM jump hosts, bastion hosts, SSH/WinRM gateways, endpoint agents (EDR)
• Observability: Session recorder, SIEM/EDR, immutable audit store (WORM)
• Automation/orchestration: SOAR for triggers, API connectors to cloud providers, AD, ticketing, CMDB

Core flows

1. Request: User requests role/elevation via portal or ticketing; policy determines required approval (risk, asset sensitivity).
2. Approval: Automated approvers (manager, resource owner, risk approver) or adaptive (MFA + risk score). Workflow engine issues ephemeral credential or token.
3. Enforcement: PAM issues time‑limited credential (vaulted secret, short‑lived IAM role via STS) and routes session through jump host/bastion with mandatory recording; conditional access blocks direct access.
4. Session control: All privileged sessions recorded (keystroke, video, command logs). Real‑time analytics pipeline flags anomalies.
5. Deprovision: On expiry or trigger, SOAR revokes token, rotates secrets, removes role assignment; IGA enforces permanent deprovision on lifecycle events.
6. Break‑glass: Emergency token with stricter audit — immediate multi‑channel alert, time‑boxed, requires post‑hoc attestation and audit.

Enforcement points

• Identity provider (conditional access) — block unless brokered
• PAM/JIT broker — issues ephemeral creds; enforces MFA and session routing
• Network/bastion hosts — force all admin protocols through gateway
• Endpoint agents — prevent lateral movement; enforce command blocking
• Cloud IAM APIs — assume role with least privilege and auto‑revoke

Automation triggers

• Time expiry (TTL)
• Approval denial or escalation
• Anomalous behavior (SIEM/UEBA/EDR alert)
• Change in user status (IGA event: terminated/role change)
• Detection of high‑risk asset access or policy violation
• Scheduled rotation windows (secrets), compliance-check triggers

Audit & compliance

• Immutable logs stored in WORM S3 or equivalent; session metadata in SIEM with links to recordings
• Automated attestation tasks for break‑glass and high‑risk sessions
• Reports for auditors: access requests, approvals, session transcripts, automated revocations

Trade‑offs & considerations

• UX vs safety: shorten TTLs, but use adaptive approval to reduce friction
• Recording legal/privacy: scope recording to privileged commands and notify users
• Resilience: replicate vaults and audit stores; fallback offline break‑glass with hardware tokens

This design delivers JIT/JEA with strong enforcement, automation-driven deprovisioning, full session visibility, and auditable emergency access — integrated across cloud and on‑prem landscapes.

Unauthorized use of an HSM (hardware security module) root key is one of the most severe possible findings in a signing pipeline, since the root key is typically the trust anchor everything else in the signing chain ultimately derives from; the response has to assume the worst about scope until evidence narrows it.

Forensic investigation

Start with the HSM's own access and operation logs (most HSMs log every cryptographic operation performed, including which key, what operation, and from which authenticated client), correlating the timeline of unauthorized use against known-legitimate signing operations to identify exactly which operations were NOT initiated by an expected, authorized pipeline. Cross-reference against network logs and authentication logs for the systems that have legitimate access to the HSM, looking for an unexpected authentication source or an authentication pattern (time of day, request volume) inconsistent with normal pipeline behavior.

Assessing scope and impact

Every artifact signed using the root key (or a key derived from it) during the window of unauthorized access has to be treated as potentially untrustworthy, not just the specific artifact that first drew attention; this means enumerating every signature produced during that window against the artifact registry and treating each one as needing re-verification or re-signing. If the root key signs intermediate keys rather than artifacts directly (a common PKI pattern), the scope assessment has to extend to everything trusted transitively through any intermediate key the root key issued or could have issued during the compromise window.

Recovery and key rotation, preserving trust where possible

The root key itself must be revoked and replaced; because it's a root of trust, this cascades: every intermediate certificate it issued needs to be re-issued from the new root, and every previously-signed artifact that relied on the old root's trust chain needs re-signing or an explicit, published transition plan customers and downstream consumers can follow (a documented key-rotation event, with the old root's revocation and the new root's public key published through the same trusted channel customers already use to verify your signatures). Where feasible, maintain the OLD root as revoked-but-documented (rather than silently disappearing) so downstream systems that cached the old root can be updated deliberately rather than suddenly failing verification with no explanation.

Trade-offs

Treating every signature from the compromise window as suspect, rather than trying to selectively determine which specific signings were the attacker's versus legitimate, is the conservative and correct choice here, even though it means re-signing artifacts that may well have been signed legitimately during that same window; the alternative, trying to cherry-pick which signings to trust, risks leaving a genuinely attacker-signed artifact in circulation because it was mistakenly judged legitimate.

I would consume the shared network with data sources or, if the network team publishes outputs, with terraform_remote_state. A data source is Terraform’s read-only lookup for existing infrastructure. I would prefer explicit outputs for IDs, because they are less ambiguous than searching by tags.

What I would check

• The VPC ID matches the expected CIDR, for example 10.20.0.0/16
• The subnet count is what I need, for example 2 private subnets in us-east-1a and us-east-1b
• Subnet tags match my assumptions, such as tier=private and env=prod
• All subnets belong to the same VPC

Fail loudly
I would add variable validation plus precondition checks so the plan stops before apply if the layout is wrong. For example, if I expect exactly 2 private subnets and only find 1, the module should error instead of guessing.

That approach keeps the module reusable, but still safe when the shared network changes.

Overview (Architect perspective)
Symmetric cryptography (e.g., AES) uses one shared secret; asymmetric (RSA, ECC) uses public/private key pairs. As an architect, choose based on performance, trust model, and operational complexity.

Performance

• Symmetric: very fast, low CPU — ideal for bulk data at scale (disk/encryption, TLS record layer).
• Asymmetric: computationally expensive (especially RSA), better with ECC for similar security at smaller keys — used sparingly (key exchange, signatures).

Key distribution & management

• Symmetric: key distribution and rotation are operational burdens; requires secure channels or KMS/HSMs, strict lifecycle and access controls.
• Asymmetric: simpler public distribution but private key protection is critical (HSMs, TPMs, strong access policies). PKI introduces certificate management, revocation, and trust anchors.

Typical use-cases

• Bulk encryption: AES (GCM) in storage and tunnels.
• Key exchange: RSA/KEM historically, now ECDH/ECDHE for forward secrecy.
• Signatures & identity: RSA/ECDSA for code signing, certificates, JWTs.

Protocols & examples

• TLS: hybrid — asymmetric for handshake (ECDHE/ECDSA), symmetric for session data (AES-GCM/ChaCha20-Poly1305).
• SSH, IPsec, S/MIME: similar hybrid patterns.

Hybrid approaches & why

• Use asymmetric to authenticate and establish ephemeral symmetric keys, then switch to symmetric for performance and forward secrecy. This balances manageability, scalability, and security—standard best practice in modern protocols.

Architectural recommendations

• Deploy PKI with HSM-backed keys, central KMS for symmetric keys, enforce rotation and least privilege, prefer ECC+AEAD ciphers, ensure forward secrecy for network protocols.

Direct answer

Asset classification tells you where to spend your limited threat-modeling and mitigation effort before you even start listing threats: an asset's classification level sets the bar for how seriously you treat threats against it, because the same threat (say, unauthorized read access) is a minor annoyance against public marketing content and a severe incident against payroll records. A typical scheme is public, internal, confidential, and secret, ordered by increasing sensitivity and increasing consequence if the confidentiality, integrity, or availability of that asset is violated. For an Human Resources (HR) data store holding personally identifiable information (PII, data that can identify a specific individual) and payroll data, that store lands at confidential or secret, which changes both which threats get analyzed first and how aggressively their mitigations get funded.

Structured elaboration

An example classification scheme

• Public: intended for unrestricted release (marketing pages, published job listings). A confidentiality breach here has little to no consequence, since the information was already meant to be public.
• Internal: meant for employees only, but not independently damaging if it leaked (internal wiki pages, org charts). A breach is embarrassing or gives a competitor minor insight, but rarely triggers a regulatory or financial event.
• Confidential: business-sensitive or personal data whose exposure causes real harm (customer PII, financial forecasts, most HR records). A breach here typically has legal, regulatory, or reputational consequences.
• Secret: the highest tier, data whose exposure causes severe, possibly irreversible harm (authentication credentials, encryption keys, payroll and banking details, health information). A breach here can trigger regulatory penalties, direct financial fraud, or harm to specific individuals.

Why classification matters for threat modeling, and how it changes prioritization

Classification is not paperwork sitting alongside the threat model, it is an input to it, in two concrete ways:

1. It changes threat identification scope. A data-flow diagram (a diagram of how data moves between processes, data stores, and external entities) for a public-content system needs a lighter pass, spoofing and denial-of-service matter more than information disclosure, since there is little to disclose. The same diagram shape for a confidential-or-higher data store needs the full STRIDE pass (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege), with information disclosure and tampering given the most scrutiny, because those are the threat categories that directly violate what makes the asset sensitive in the first place.
2. It changes mitigation prioritization. When two findings compete for the same sprint's engineering time, the one touching the higher-classified asset wins, all else equal, because the expected harm from a realized threat scales with classification. A medium-likelihood finding against a secret-tier asset is typically prioritized over a high-likelihood finding against a public-tier asset, since the consequence term in a likelihood-times-impact assessment is what classification is directly encoding.

Applied to the HR data store

An HR data store containing PII and payroll data is not internal, and arguably not merely confidential either, because it combines two distinct sensitivity drivers: PII triggers privacy-regulation obligations (many jurisdictions have specific legal requirements for how PII must be protected and what happens if it is exposed), and payroll data is financially sensitive in its own right (bank account numbers, compensation figures) with direct fraud potential if disclosed or tampered with. A reasonable classification is confidential for general HR records and secret for the payroll and banking-detail subset specifically, since that subset has the highest direct-fraud potential if tampered with or disclosed. That split matters in practice: it means the threat model treats the payroll subsystem's trust boundaries (who can read it, who can write to it, what logs its access) with the tightest scrutiny, while general HR records (job titles, org structure) get real but comparatively lighter scrutiny.

Worked example

Take two findings from a threat model of an HR system: Finding A is a medium-likelihood information-disclosure risk on the general employee-directory service (classified internal to confidential, mostly names and job titles), and Finding B is a medium-likelihood information-disclosure risk on the payroll service (classified secret). Both findings have the same likelihood rating and the same threat category. Classification is what breaks the tie: Finding B is prioritized first, because the consequence of the same threat materializing is categorically higher, direct financial and privacy harm to individuals versus reputational embarrassment. Without classification as an explicit input, both findings would look identical on a bare likelihood scale, and prioritization would have no principled basis for choosing between them.

Trade-offs and pitfalls

• The common wrong turn is classifying at the system level instead of the asset level. Calling the entire HR system "confidential" and stopping there misses that the payroll subset inside it deserves stricter treatment than the org-chart subset; classification should be granular enough to actually drive different mitigation decisions within one system, not just a single label on the whole thing.
• Classifying everything as the highest tier "to be safe" defeats the purpose: it removes classification's ability to prioritize at all, since prioritization only works if it can distinguish between assets.
• Classifying once and never revisiting it misses that a data store's sensitivity can change, for example if a previously internal-only HR system starts also storing bank details for direct-deposit payroll, which should trigger a reclassification and a fresh look at that asset's threats, not a threat model that quietly continues operating on a stale classification.

Direct answer

Eventual consistency means that after writes stop, all copies of the data will eventually agree, but there's a window, sometimes milliseconds, sometimes longer, during which different readers can see different, both "correct at the time" answers. For a non-technical stakeholder, the useful line is: the system prioritizes staying responsive everywhere over making everyone see the same thing at the exact same instant. Below are three analogies for that idea, each with the one place it will mislead if you don't say it out loud.

Choosing the analogy and what to omit

• Pick an analogy where the delay AND the reconciliation are both visible, not just the delay. Many weak analogies (mail, gossip) only show that news travels slowly; they hide the harder part, what happens when two people acted on different information during that delay.
• Decide up front which mechanism you're omitting: you're almost always omitting HOW the system decides which write wins when two conflict. Say that you're leaving it out, rather than letting the analogy imply there's no rule for it at all.
• Check understanding by asking them to predict a scenario, not recite the definition back: "if two people edit this at the same moment from different offices, what do you think happens?" A correct prediction means the model landed; an answer that assumes instant sync means you need to go back to the delay itself.
• The same shape, plain definition, one concrete example, why it matters, holds for any jargon-heavy term a non-technical audience needs defined on the spot: ETL vs ELT (does the transformation happen before or after loading), ACID vs BASE (strict correctness vs eventual, available correctness, which is this same idea from the database's side), or REST vs GraphQL (fetch a fixed shape of data vs ask for exactly the fields you need). Same competency, different vocabulary each time.

Worked example

1. A group chat where one person's phone is off. You send a message to a group chat; everyone online sees it in under a second. Someone whose phone died an hour ago won't see it until they turn it back on, at which point it downloads and they're caught up. What it shows well: the "everyone gets there eventually, but not at the same time" shape, and that being offline doesn't break the system, it just delays that one reader. Where it misleads: it implies messages simply queue up in order. If two people update the SAME piece of shared data while a third is disconnected, there can be a genuine conflict to resolve, not just a backlog to deliver, and the chat analogy has no equivalent of "two people edited the same message."

2. A retail chain updating a sale price across stores. Head office cuts a price. Each store's system checks for updates on its own schedule, so for a few minutes Store A shows the new price and Store B still shows the old one. What it shows well: the same data existing in multiple places, each catching up on its own timeline, with no single moment where everyone updates at once. Where it misleads: it suggests the only direction of change is head office to stores, one writer, many readers. Real eventually consistent systems often allow writes at multiple locations at once, a customer changing their address from two devices, and that's where the interesting conflicts and reconciliation rules actually come from.

3. Watering one end of a long garden bed. You water one end of a dry garden bed and moisture visibly spreads down the row over the next hour until it's evenly damp. What it shows well: gradual, automatic convergence toward one final state with no single "sync" event. Where it misleads: soil moisture always converges smoothly. Some real systems can get stuck in a genuine conflict that never resolves on its own, two writes with no way to tell which should win, and need a rule, or a human, to break the tie. "It'll just even out" is the sentence most likely to leave a stakeholder with a false sense of safety.

Trade-offs and pitfalls

The single biggest risk in any of these analogies is implying the temporary disagreement is harmless. For some products it is, a slightly stale follower count. For others it isn't, two systems both believing they hold the last unit of inventory. Say plainly which case you're in. Also resist stacking all three analogies in one conversation; one that survives a follow-up question beats three shallow ones, use the extra two only if the first one visibly didn't land.

Definition — fail-secure (fail-closed) vs fail-open

• Fail-secure / fail-closed: on failure, system denies access or halts functionality to prevent security breaches (preserves confidentiality/integrity at cost of availability).
• Fail-open: on failure, system continues to operate with reduced controls to preserve availability (increases risk to confidentiality/integrity).

Decision for each system

1. Authentication service — Prefer fail-secure

• Justification: Authentication is a primary gatekeeper. Failing closed prevents unauthorized access, limiting blast radius. Availability strategies (redundancy, graceful degradation like read-only cached tokens) should be used so failing closed doesn’t block critical business processes.

2. Payment gateway — Prefer fail-secure

• Justification: Financial transactions must protect integrity and anti-fraud controls. Allowing payments on degraded or unverified channels risks fraud and regulatory violations. Use high-availability design (active-active, circuit breakers, offline reconciliation) rather than fail-open.

3. Operational monitoring pipeline — Prefer fail-open (with caveats)

• Justification: Monitoring supports incident response; blocking telemetry worsens outages. Prefer best-effort delivery on failure (buffering, degraded sampling) but mark data as degraded and preserve integrity controls where feasible. For sensitive logs, apply selective fail-secure behavior (drop non-essential telemetry that risks leakage).

Architectural notes

• Choose behavior per threat/risk assessment; implement compensating controls (redundancy, caching, alerts, manual overrides, audit trails).

Direct answer

A threat model for an enterprise identity and access management (IAM) platform should walk each stage where trust is established or extended, credential issuance, token use, account elevation, and inter-system access, and ask what an attacker gains at each stage and what specific control catches or blocks it. The six vectors named here span three parts of that lifecycle: the integrity of tokens and the identity provider (IdP) that issues them, the moment an identity is created or elevated, and what an attacker does after gaining an initial foothold.

Structured elaboration

This applies STRIDE-style reasoning (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege, the standard threat-categorization lens) directly to the IAM platform rather than teaching the methodology itself. For each vector: what the attacker actually does, the primary preventive mitigation, how you would detect it, and a compensating control that limits damage if the primary mitigation is absent or fails.

Worked example

A realistic chained attack shows why treating these six vectors in isolation understates the real risk. An attacker phishes a push-based MFA approval from a standard user (account takeover). From that lower-privileged foothold, they discover a service account with excessive standing permissions, including access to the IdP's admin console, and use it to escalate (privileged escalation, enabled by the absence of just-in-time elevation). With admin access to the IdP, they attempt to add a new federation trust so their own external identity provider is accepted as authoritative (an IdP compromise attempt). Reading this chain against the table above: the account-takeover step should have been caught by new-device login alerting; if it was not, the privileged-escalation step should have been caught by alerting on the elevation event itself, since a standard user reaching admin-console access is a clear deviation from baseline; if that was also missed, the IdP's own admin audit log monitoring for a newly-added federation trust is the last line before the attacker has durable, org-wide token-minting capability. No single control in the table is expected to be perfect, the chain is stopped by whichever layer actually catches it, which is the point of listing detection strategies at every stage rather than only at the first one.

Trade-offs and pitfalls

• Treating each vector as independent understates chained risk. As the worked example shows, a weak mitigation at one stage (no JIT elevation, so standing over-permissioned service accounts exist) turns a low-severity account takeover into a high-severity IdP compromise attempt. A mature threat model reviews chains across vectors, not just each row of the table in isolation.
• Detection-only coverage for the IdP-compromise vector is not enough given its blast radius. Because a compromised IdP can mint tokens for any identity, this is the one vector where the compensating control (short token lifetime plus a rehearsed rollover runbook) matters as much as the primary mitigation; relying purely on detecting the compromise after the fact leaves too large a window of full-organization exposure.
• Just-in-time elevation without session recording only half-solves privileged escalation. JIT reduces the window an elevated credential exists, but without session recording and brokering, a successful escalation inside that window is still unobserved; the two controls are complementary, not substitutes.
• A common wrong turn is treating provisioning abuse as purely a technical control problem. Dual-control approval workflows help, but the compensating control that actually catches a determined insider or a coerced approver is the human process of periodic access review, a technical gate alone does not substitute for someone actively re-certifying access on a cadence.