2 min lesson
Okta-as-code, concretely
Use the example in "Okta-as-code, concretely" to explain the main idea in plain words.
Step 1 of 2
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.
Once config lives in Git, you can assert on it. A CI check can fail any PR that grants an app to "Everyone" instead of a scoped group or that creates an admin role without an approval label. That progression - manual clicks, to declared config, to policy enforced in CI - is the "engineering-driven IT" story the role is built around. Say it as a trajectory, not a single tool.
If asked how you'd manage Okta or Workspace, don't describe the admin UI. Say: "I'd keep the tenant in Terraform, granted by group, reviewed in PRs, with plan running in CI to catch drift - so every access change is logged, reversible and audit-ready." Then name the honest limit: provider coverage isn't 100%, so a few corners stay manual and you document those gaps rather than pretending they don't exist.