Automation, IaC & Zero-Trust Engineering

The first technical screen is a hands-on scripting round and the bar is not "can you write Python." It's whether you reach for code by default to make a manual IT process disappear and whether the script you write would survive contact with a real Okta tenant.

Cursor frames this role as software engineering applied to IT. The interviewer is reading for an engineer's mindset: you hit a SaaS REST API, you handle the pagination and the 429s and you make the thing safe to run twice. A candidate who writes a one-shot script that double-creates users on a re-run has told the interviewer they've never run automation in anger.

The four properties graders look forwhat separates a script from a toy

Talk to a SaaS API the way the API expectsOkta, Google, Slack all bite the same way

Every IT-facing API has the same three traps: it pages its results, it rate-limits you and it occasionally 500s mid-batch. A senior answer wires all three into a small reusable client rather than copy-pasting requests.get everywhere.

import os, time, logging, requests

OKTA = os.environ["OKTA_ORG_URL"]            # injected, never hard-coded
TOKEN = os.environ["OKTA_API_TOKEN"]         # from the secrets manager
S = requests.Session()
S.headers.update({"Authorization": f"SSWS {TOKEN}"})
log = logging.getLogger("jml")

def get_all(path):
    """Follow Okta's Link: rel=next paging, retry on 429/5xx."""
    url, out = f"{OKTA}{path}", []
    while url:
        for attempt in range(5):
            r = S.get(url, timeout=30)
            if r.status_code == 429 or r.status_code >= 500:
                wait = int(r.headers.get("Retry-After", 2 ** attempt))
                log.warning("throttled, sleeping %ss", wait); time.sleep(wait); continue
            r.raise_for_status(); break
        else:
            raise RuntimeError(f"gave up on {url}")
        out += r.json()
        url = r.links.get("next", {}).get("url")
    return out

def converge_membership(group_id, desired_ids, dry_run=True):
    current = {u["id"] for u in get_all(f"/api/v1/groups/{group_id}/users")}
    add, remove = desired_ids - current, current - desired_ids
    log.info("group %s: +%d -%d", group_id, len(add), len(remove))
    if dry_run:
        return {"add": sorted(add), "remove": sorted(remove)}   # show the diff, change nothing
    for uid in add:
        S.put(f"{OKTA}/api/v1/groups/{group_id}/users/{uid}", timeout=30).raise_for_status()
    for uid in remove:
        S.delete(f"{OKTA}/api/v1/groups/{group_id}/users/{uid}", timeout=30).raise_for_status()
    return {"added": len(add), "removed": len(remove)}

Notice the shape: read the current state, compute a diff against desired and apply only the delta. That's a reconcile-and-converge loop and it's idempotent for free because a second run finds nothing to change.

Pick the right trigger for the jobreconcile loop vs. webhook vs. cron

The strong pattern for joiner/mover/leaver is a webhook for immediacy plus a reconcile loop on a schedule as the safety net. Webhooks get dropped; a converge loop catches whatever the event missed.

This is the literal nice-to-have in the job description and the heart of the "transform traditional IT" pitch. The interviewer wants to hear that your Okta config, your Google Workspace settings and your fleet baselines live in Git and ship through a pull request - not in someone's memory of which checkbox they clicked.

Click-ops is the failure mode this role exists to kill. When an SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. app is configured by hand, there's no review, no history of who changed the assertion attribute and no way to recreate it after a bad edit. Config-as-code gives you the same disciplines engineers already have for application code.

Five things Git gives IT configthe benefits to articulate by name

Pick the tool to the layerTerraform/Pulumi vs. Ansible

You don't have to choose only one. A common setup is Terraform managing the Okta tenant and Google Workspace, with Ansible handling Linux server baselines, all in the same repo behind the same review gate.

Okta-as-code, concretelywhat a reviewer can read in a PR

resource "okta_app_saml" "datadog" {
  label                    = "Datadog"
  sso_url                  = "https://app.datadoghq.com/account/saml/assertion"
  recipient                = "https://app.datadoghq.com/account/saml/assertion"
  destination              = "https://app.datadoghq.com/account/saml/assertion"
  audience                 = "https://app.datadoghq.com/account/saml/metadata"
  subject_name_id_template = "$${user.email}"
  subject_name_id_format   = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
  honor_force_authn        = true
}

# Access is granted by group, not by user - least privilege, reviewable
resource "okta_app_group_assignments" "datadog" {
  app_id = okta_app_saml.datadog.id
  group {
    id = okta_group.eng_observability.id
  }
}

A reviewer can see exactly which group gets the app and that the NameID is the email. If someone later loosens honor_force_authn in the console, the next terraform plan flags the drift and the PR history shows the intended state.

The systems-design screen will likely ask you to design an access model end-to-end and the expected frame is zero-trust. The mental shift is from a castle-and-moat - trusted once you're on the VPN - to verifying identity, device and context on every single request.

The old model trusts the network. Get onto the corporate LAN or VPN and you're inside the walls, free to move laterally. Zero-trust deletes the inside: there is no trusted network, every resource sits behind a check and trust is recomputed per request from live signals.

The four principles, said plainlyname them, then show them in a design

Combine signals - no single one is enoughidentity AND device AND context

A stolen password alone shouldn't open anything. The access decision is a function of several independent signals and the strong design fuses them rather than leaning on one.

ZTNA replaces flat VPN trustidentity-aware proxy + micro-segmentation

A VPN grants broad network access once connected, which is exactly the lateral-movement problem assume-breach warns about. ZTNA puts an identity-aware proxy in front of each application, so a user reaches only the specific apps their identity and device posture allow and reaches nothing else on the network.

Roll it out without breaking everyone's dayphased enforcement, not a flag-day cutover

1. 1Inventory and baseline. Map apps, who needs them and current device posture. You can't enforce policy on access you haven't mapped.
2. 2Deploy in monitor mode. Run the proxy and posture checks logging-only first, so you see who would be blocked before anyone is.
3. 3Enforce in rings. Start with IT and a friendly pilot team, expand by group, keeping a clear exception path for the legitimately-blocked.
4. 4Communicate ahead of each ring. Tell users what's changing, why and how to get unblocked - surprise enforcement generates tickets and resentment.
5. 5Tighten over time. Once steady, ratchet down: shorter sessions, stricter posture, fewer exceptions and retire the old VPN path.

The reframe that lands in this loop: IT systems are services with uptime, not a queue of one-off tasks. An offboarding pipeline that silently fails is a security incident, not a missed chore - and you find out from a dashboard, not from the ex-employee still in Slack a week later.

Once you've automated JML and access, those automations are infrastructure. They need the same operational treatment a production engineer gives a service: monitoring, alerting, SLOs, on-call thinking and postmortems that turn into permanent fixes.

Monitor the automations, not just the appsthe pipeline is the thing that breaks

SLOs for internal serviceswrite the promise down

Internal IT deserves measurable targets the same way an API does. The sharpest example for this role is offboarding latency, because it's a security control with a clock on it.

Runbooks and on-call for ITwhen SSO or offboarding breaks at 5pm Friday

1. 1Detect. An alert fires on the symptom (provisioning failed, SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. error rate up) with context: which system, which user, what changed.
2. 2Triage and contain. If SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. is down org-wide, that's a sev-1; if offboarding stalled, manually revoke the highest-risk access first while you fix the pipeline.
3. 3Follow the runbook. Each critical system has a written runbook: how to detect, the manual fallback, who to escalate to and the rollback step.
4. 4Restore and verify. Confirm the fix with the same check that should have caught it - re-run the reconcile loop and confirm convergence.
5. 5Postmortem, blamelessly. Find the systemic cause, then convert the fix into automation or a new alert so this exact failure can't recur silently.

The job description's sample projects literally name AI-assisted employee support and self-service IT. At a company that builds an AI code editor, there's an implicit authenticity bar: they want someone who already uses Cursor and AI daily and who has built - not just imagined - AI-assisted internal tooling.

Two things make this section land. First, concrete patterns you can describe at the design level. Second, real examples you've actually shipped, because the AI-native check is hard to fake and the interviewer will probe for specifics.

Patterns worth bringingwhat AI-native IT actually looks like

Guardrails are the senior signalAI that touches access needs a leash

Anyone can wire an LLM to an API. The judgment the role wants is knowing where to put the human and the audit trail, because an agent with unsupervised access to your IdP is a liability, not a feature.

• Human-in-the-loop for privileged actions. Auto-execute the safe, reversible, pre-approved requests; route anything that grants elevated access, touches admin roles or deviates from policy to a human approval.
• Log and review AI-driven changes. Every action an agent takes lands in the same audit trail as a human change, tagged as AI-initiated, so it's reviewable after the fact.
• Bound the blast radiusHow much breaks if a change goes wrong; the scope of potential damage.. Give the agent a narrow, least-privilege scope of actions it's allowed to take - not your full admin token.
• Keep a kill switch and a clear fallback. If the agent misbehaves, you can disable it and the manual path still works.

Two responsibilities collapse into one skill here: passing a SOC 2 / ISO 27001 audit and integrating an acquired company's IT. Both reward the same instinct - turn a manual, error-prone, point-in-time effort into version-controlled, automated, continuously-true systems.

Auditors and acquisitions both punish click-ops. If access reviews live in a spreadsheet and integrations live in someone's head, you get a fire drill every audit cycle and a risky scramble every deal. Automation makes both routine.

Map controls to your systemsspeak the auditor's language

The M&A integration playbookmerge identity, devices and SaaS

1. 1Inventory the acquired stack. Catalog their IdP, domains, SaaS apps, devices and admins. You can't migrate or de-dupe what you haven't enumerated.
2. 2Consolidate identity and domains. Decide the target IdP and email domain, then plan the identity migration - usually fold their users into your Okta/Workspace as the source of truth.
3. 3Migrate identities and access. Provision accounts in the target, map groups to your RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually. model and grant least-privilege rather than copying their (likely looser) access wholesale.
4. 4Re-enroll devices. Bring their fleet under your MDM - zero-touch where the hardware supports it (ABM/Autopilot), staged so people aren't all locked out at once.
5. 5De-dupe SaaS and cut over. Find overlapping tools, consolidate licenses, migrate data and decommission the redundant tenants - with a rollback plan and a sequenced, not big-bang, cutover.

Sequence to minimize disruption and gapsthe part that shows you've done it

The risk in any cutover is twofold: locking people out of tools they need and leaving a security gap during the transition (two IdPs both live, stale admin accounts, devices half-enrolled). Sequence so each step is reversible and the window where both old and new systems are active is as short as you can make it.