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.

Context & goals
Protect confidentiality, integrity and availability of critical workloads by applying secure-by-default configurations, defense-in-depth, least privilege, and a tested upgrade/patch cadence.

RBAC (least privilege)

• Default deny cluster-admin to teams; use narrowly scoped Roles/RoleBindings.
• Use groups from IdP (OIDC) and short-lived tokens.
• Enable audit logging for authz decisions and review anomalous grants.
  Example: grant only get/list/patch on secrets to a service account:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: secret-reader, namespace: prod }
rules:
- apiGroups: [""] 
  resources: ["secrets"]
  verbs: ["get","list"]

Admission controllers

• Enforce: PodSecurity (enforce baseline/restricted), NodeRestriction, AlwaysPullImages, ImagePolicyWebhook, ValidatingAdmissionWebhook (OPA/Gatekeeper).
• Implement policy catalog in Gatekeeper/OPA: disallow privileged containers, require seccomp profiles, require resource limits, image provenance.

Image signing & supply chain

• Require signed images (Sigstore/cosign or Notary), enforce with ImagePolicyWebhook.
• Use SBOMs, provenance metadata, vulnerability scanning in CI (CVEs block deploys above threshold).
• Immutable registries and image pullFromAllowed list.

Network policies

• Default deny ingress/egress at namespace level.
• Micro-segmentation by app tier; allow only necessary ports and endpoints; isolate management plane.
  Example:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: deny-all, namespace: prod }
spec:
  podSelector: {}
  policyTypes: ["Ingress","Egress"]

Container runtime options

• Enforce noNewPrivileges, readOnlyRootFilesystem, drop ALL capabilities, add only needed ones.
• Use seccomp/defaultAppArmor profile, enable runtime metrics with process isolation.
• Limit sysctls and disable privileged hosts.

Node hardening

• Apply CIS Kubernetes benchmarks; minimal host OS image, immutable nodes, disable unused services.
• Kubelet secured: TLS bootstrapping, client certs, authn/authz, restrict kubelet API access.
• Patch kernel/options: disable ip forwarding if unused, sysctl hardening.
• Use host OS attestation (TUF/TPM) and Node attestation for joining nodes.

Monitoring, logging, & incident readiness

• Centralized immutable logs, EDR on nodes, runtime security (Falco), alerting for policy violations.
• Periodic chaos/pen tests and simulated compromise exercises.

Cluster upgrade & patch practice

• Define maintenance windows, automated patch baseline for CVEs, stage upgrades: canary -> non-prod -> prod.
• Use blue/green or rolling upgrades with health checks; keep control plane and kubelet within supported version skew.
• Emergency hotfix process with approved rollback plan and post-mortem.

Trade-offs: stricter defaults increase operational friction—mitigate via developer onboarding, automated policy fixes and clear exception workflows.

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.

Direct answer

End-to-end encryption (E2EE) means only the sending and receiving devices ever hold the keys needed to read a message's content; the server only ever handles ciphertext. The hard part of this design isn't the cryptography itself, well-established protocols already exist, it's building group chat, multi-device sync, and any server-assisted feature without ever giving the server a decryption path, which each of those features would naturally want if you weren't deliberate about it.

Structured elaboration

Client and server responsibilities. The client generates and stores all key material, encrypts every outgoing message, decrypts every incoming one, and performs key exchange with other devices and users directly, with the server only relaying the exchange messages, never reading them. The server relays ciphertext, stores it temporarily for offline delivery until a recipient device comes back online, and handles the metadata needed to route messages, who sent what to whom, when, but must have no code path capable of decrypting content.

Key hierarchy. Each device holds a long-term identity key pair that proves which device belongs to which user. For one-to-one conversations, a continuously re-keying session mechanism (a Double Ratchet-style design) derives a fresh key for every message, so compromising one message's key does not expose past or future messages, a property called forward secrecy. For group chats, a shared group key, or a per-member sender key others also hold, is distributed to every current member through pairwise one-to-one encrypted channels first, avoiding an expensive full pairwise fan-out for every individual group message. When someone joins or leaves the group, the group key is rotated: a new key is generated and redistributed pairwise only to the remaining members, so a removed member's device cannot decrypt future messages even though it still holds whatever history it already received before removal.

Device syncing. Adding a new device gives it its own identity key, and existing devices or contacts must securely deliver the relevant session keys to it, typically via the same pairwise encrypted exchange, verified by an out-of-band or in-app safety-number or QR-code check. That verification step specifically defends against a malicious server quietly inserting a fake device into the key exchange, sometimes called a key-substitution or ghost-device attack.

Limited server-side search. Since the server never has plaintext, search either happens entirely on-device, each client searching its own locally decrypted message store, which works for single-device search but doesn't span devices without extra design, or uses an encrypted keyword-index technique similar to the equality and blind-index approaches used for searchable encrypted database fields generally, with the same equality and frequency leakage caveats applying here too (a blind index is a searchable fingerprint of a value that lets the server match equal values without ever seeing the values themselves; equality leakage means the server can still tell that two entries hold the same value, and frequency leakage means it can see how often each value appears). There is no server-assisted search option that gives up nothing.

Lawful access or eDiscovery from the operator's own legal team. In a properly designed E2EE system, the operator genuinely cannot produce plaintext under a valid legal order, because it was never in a position to have it. What the operator can still produce is whatever metadata it does hold, who talked to whom, when, message sizes, delivery timestamps, which is exactly why minimizing that metadata matters so much: it's the part legal process can actually reach. If a business or regulatory need genuinely requires the operator to produce plaintext under compulsion, that is a fundamentally different, non-E2EE architecture, and the honest answer to a stakeholder asking for "E2EE, but with a way for us to read messages when legally compelled" is that the two requirements are close to mutually exclusive by design, since any mechanism giving the operator that path is also a channel an attacker, or a compromised operator, could use.

Metadata to minimize even though content is protected. Avoid retaining message-derived metadata beyond what delivery actually requires, round or bucket timestamps where feasible rather than keeping exact ones, and avoid keeping full social-graph history longer than the relay function needs, since delivery-timestamp and message-size metadata alone can reveal a surprising amount about conversation patterns even with content fully protected. Offline delivery requires the server to buffer ciphertext until the recipient is next online, which is fine since it's already ciphertext, but how long undelivered messages sit in that queue is itself a retention and privacy decision worth setting deliberately. The server can still compute coarse operational aggregates, total message volume, active user counts, from metadata alone without touching content, but even those aggregates need review so they don't inadvertently correlate with known message-size patterns.

Worked example

flowchart TD
    ID[Device identity key<br/>long-term, one per device] --> RATCHET[Session ratchet key<br/>per 1:1 conversation, rotates every message]
    ID --> GROUPDIST[Pairwise key distribution<br/>to each group member's device]
    GROUPDIST --> GROUPKEY[Group message key<br/>shared by current members]
    RATCHET --> MSG1[1:1 message ciphertext]
    GROUPKEY --> MSG2[Group message ciphertext]
    MSG1 --> SERVER[Server: relays ciphertext only<br/>stores minimal routing metadata]
    MSG2 --> SERVER
    SERVER -->|offline queue| RECIPIENT[Recipient device, decrypts locally]
    MEMBERCHANGE[Membership change: join or leave] --> GROUPDIST

Every arrow into the server carries only ciphertext and routing metadata; the identity key, ratchet key, and group key never leave the devices that hold them, and a membership change flows straight back into pairwise redistribution, not into anything the server can act on.

Trade-offs and pitfalls

A common way E2EE quietly breaks is adding a convenience feature, link previews, spam scanning, cloud backup, that requires handing the server or a backup service plaintext or a copy of a key. Every new feature request against a system like this should be evaluated as "can this be done fully client-side" before assuming a server-side implementation is acceptable, because it usually isn't compatible with the property the system is named for.

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.

Overview / Goal
Provide a concise, executive-ready KPI set that proves controls are effective, demonstrates improving security posture, and supports audit evidence.

Core KPIs & Definitions

• Control Coverage: % of in-scope assets/processes with required control implemented
  • Calculation:

Control Coverage = (Number of assets with control implemented / Total in-scope assets) * 100%

• Mean Time to Detect (MTTD): average time from incident start or control failure to detection

MTTD = Sum(detection time - start time) / Number of incidents

• Mean Time to Remediate (MTTR): average time from detection to remediation/closure

MTTR = Sum(remediation time - detection time) / Number of incidents

• Remediation Velocity: % of findings closed within SLA window (e.g., 30/60/90 days)
• Evidence Freshness: median age of supporting evidence per control (days)
• Control Exception Trend: rolling 90-day count and severity-weighted rate of exceptions

Supporting Metrics

• False-positive rate (detection quality)
• Repeat-finding rate (recurrence)
• Audit pass-rate by control family

Dashboard Layout (Executive / Audit Tabs)

• Top row (Executive summary): Overall Risk Score, Control Coverage, MTTD, MTTR, Remediation Velocity (gauges)
• Middle row: Trend charts (30/90/365 days) for MTTD, MTTR, Exceptions by severity
• Lower row: Heatmap of coverage by business unit, evidence freshness table, top 10 open findings with age and owner
• Audit view: Per-control evidence links, timestamped evidence history, exception approvals

Thresholds / Targets

• Set targets by risk tier:
  • Critical controls: Coverage >= 99%, MTTD < 1 hour, MTTR < 24 hours, Remediation Velocity 95% within SLA
  • High: Coverage >= 95%, MTTD < 4 hours, MTTR < 72 hours, Remediation Velocity 90%
  • Medium/Low: progressive relaxed targets
• Evidence Freshness target: < 30 days (or per control-specific cadence)
• Exception trend: target zero increasing trend; define alert when 3-month trend slope > +10%

Implementation & Governance

• Map KPIs to control owners, automate data collection from SIEM, GRC, ticketing, CMDB
• Quarterly review with execs + monthly operational review
• Use targets as control SLAs; escalate deviations via RACI and runbooks

Why this works: combines coverage, speed, quality, and evidence to show both technical effectiveness and auditability, with thresholds tied to business risk.

Direct answer. A secure-by-design checklist is a short list of questions a new service must answer with evidence before launch. I would keep it to ten items, make seven of them launch blockers (mandatory), leave three as advisory, and stop it becoming a rubber stamp by demanding links to proof, giving the reviewer a real "not ready" outcome, and auditing the reviews themselves.

Key terms. An architecture review is a design-time meeting where a security architect examines a new service before it ships. Mandatory means the item blocks launch unless a named approver signs a written, time-limited exception. Advisory means the team answers in one line and the reviewer may recommend, not require. A rubber stamp is a review where every box gets ticked without anyone checking the claim. A trust boundary is a line on a diagram where data passes between parts that are trusted differently, such as browser to server, or your service to a third party. A negative test is a test that tries something that must be refused and passes only when it is refused. An egress allow-list is the list of outside destinations a service may call, with every other outbound connection blocked. Network segmentation means splitting the network into zones so that a compromised component cannot reach everything.

The checklist (10 items, 7 mandatory, 3 advisory)

Seven mandatory plus three advisory is the full set of ten.

One row, bounced and accepted (illustrative). Take item 2 for a new orders service. Bounced: the form says "Authorization: Yes" and nothing else. Accepted: "Every route passes through the require_user check; ownership is checked in the order lookup (link to the code). The test user_a_cannot_read_user_b_order returns 403 and ran in pipeline run 4121 (link)." The reviewer opens the test and confirms it runs in the pipeline, not only on a laptop. The first version cannot be checked by anyone; the second can be checked in two minutes.

What decides the tier. An item is mandatory when failing it can expose customer data or let one tenant reach another, and when the fix is cheap before launch and expensive after. Anything that only adds a further layer of defense in depth (an additional, independent control behind the first) is advisory, because the service stays safe if it is missing. Two further items are mandatory by a second test: they are the controls that let us detect or limit damage when a first control fails. Logging and detection (item 5) cannot stop a breach, but without it nobody would notice one, and build integrity (item 7) decides whether what runs is what was reviewed. Abuse controls (item 8) are advisory only for a service with no public or unauthenticated endpoint; for a login page or public API, missing rate limits allow credential stuffing (trying stolen username and password pairs at volume), so the item becomes mandatory for that service. The tier is set per service, so the table shows the default for a typical internal service.

Five ways to stop it becoming a rubber stamp

1. Evidence, not ticks. Each mandatory row needs a link to a diagram, configuration, or test result. "Yes" with no link counts as "no".
2. Questions that force a story. Beside each item sits one prompt such as "describe what happens to a request when the identity provider is unreachable". A team that has not thought about it cannot answer fluently.
3. A real fail outcome. The reviewer can return "not ready", and I track how often that happens. A checklist that has never blocked anything is decoration.
4. Audit the reviews. Each quarter, pick a random sample of approved services and re-check the claims against the live configuration. Differences between what was claimed and what is deployed are the finding.
5. Measure outcomes. Track the share of reviews that changed the design, the number and age of open exceptions, and incidents traced to reviewed services. If reviews change nothing, the review is too late or too shallow.

Trade-offs and pitfalls. A long list gets skimmed, so resist adding an item after every incident; retire or merge items instead. Tailor depth to risk: an internal tool with no sensitive data gets a lighter pass than a payment service. Run the review during design, not the week before launch, or "mandatory" turns into a fight about the date.

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.