SailPointIdentity Security Cloud

SailPoint ISC Admin Exam – Plain-English Study Guide

Built from your Complete Exam Blueprint, the SailPoint ISC administrator documentation, and SailPoint Developer Community notes. Every topic on the blueprint is explained in simple language, with an Exam tip where a detail tends to be tested.

Note: SailPoint's docs now brand the product "SailPoint Human Fabric". It is the same product you know as Identity Security Cloud (ISC). Your exam may use either name.

The Big Picture (learn this first)

Almost every topic on the blueprint fits into one flow. If you can narrate this flow, you can answer most scenario questions:

  1. Sources hold accounts (HR system, Active Directory, apps).
  2. Aggregation pulls those accounts into ISC.
  3. Correlation matches each account to a person (an identity).
  4. Identity Profile (built on an authoritative source) creates identities and fills their attributes through mappings and transforms.
  5. Lifecycle states and roles decide what access each identity should have.
  6. Provisioning pushes that access (create, enable, disable, add, remove) back to the sources.
  7. Governance keeps it safe: access requests, approvals, certifications, policies and SoD.
  8. Platform and Virtual Appliances are the plumbing that keeps all of this running and secure.

When a question describes a problem, ask yourself: at which step of this flow did it break?

Domain 1 – Platform

Reports

Reports are downloadable summaries (CSV or PDF) for audit and operations. Examples: identity details, access/entitlement reports, and the Uncorrelated Accounts report (accounts that did not match any identity) and a report of identities without managers. The Report Admin user level exists so someone can run reports without being a full admin.

Exam tip: After aggregating a source, run the Uncorrelated Accounts report to confirm accounts matched identities.

OAuth and PAT (Personal Access Tokens)

Both are ways for scripts and applications to call ISC APIs without using a person's username and password.

API client (OAuth client ID and secret). Created under Admin > Global > Security Settings > API Management. You pick a grant type (for example client credentials, authorization code, refresh token), pick scopes, and ISC gives you a client ID and secret. The secret is shown once. Copy it immediately or you must delete and recreate the key.

Personal Access Token (PAT). Created by a user under their Preferences > Personal Access Tokens. It acts as that user, so it can never do more than that user's user levels allow.

Key facts:

  • Each user can have up to 10 PATs.
  • Default expiry is 6 months. If you clear the date, the token never expires (risky).
  • An expired PAT can be restored for up to 3 months by updating its expiry.
  • Scope changes can take up to 30 minutes to apply.
  • The scope sp:scopes:all means "everything the user's levels allow". For least privilege, select only the scopes you need.
  • Org Admins can see all user-created PATs in one place and update expiry in bulk (up to 25 at once).
  • Important gotcha: generic API keys fail on search for roles, entitlements or identities when Data Segmentation is on, because the key is not tied to a person. Use a PAT instead.
  • A VA key is created automatically with a VA and can only be removed by deleting the VA.

Exam tip: "Integration needs to call APIs as a specific user, with that user's limits" = PAT. "Application-to-application with its own credentials" = API client with client credentials.

Workflows

A workflow is ISC's built-in automation: trigger → steps. You build it in a visual editor. Think of it as "when X happens, do Y".

The parts:

  • Trigger: what starts it (see Triggers below).
  • Actions: things it does, for example send an email, call an HTTP endpoint, get or update an identity, create a form, disable an account, start a campaign.
  • Operators: decision and flow logic, for example compare values, branch on a condition, wait, loop.
  • Interactive process: workflows can pause and ask a person to fill a form or approve something.
  • JSONPath expressions: how steps read data from earlier steps, for example reading the identity ID from the trigger's data.
  • Templates: ready-made starting points.

You can test a workflow and review its execution history to see where it failed.

Exam tip: Questions often describe a business need ("when a new identity is created, email the manager") and ask which feature solves it. If no connector or role can do it, the answer is usually a workflow.

Triggers

Triggers are the events that start workflows (or notify external systems). ISC sends a message the moment something happens, so nobody has to keep polling an API.

Two kinds of event triggers:

  • FIRE_AND_FORGET: ISC announces the event and moves on. Examples: Identity Created, Identity Attributes Changed, Access Request Decision, Source Created, Scheduled Search.
  • REQUEST_RESPONSE: ISC waits for an answer. Examples: Access Request Submitted (pre-approval) and Access Request Dynamic Approval, where your system replies with who should approve. Each of these can have only one subscription.

Other trigger styles for workflows: scheduled (runs on a timer), external/generic (called by an outside system through a URL), and form submitted.

Subscriptions can deliver to an HTTP endpoint, a workflow, or other supported targets. Busy triggers can create huge volumes, so use event filters to only react to what you care about.

Exam tip: Know the FIRE_AND_FORGET vs REQUEST_RESPONSE difference. Only REQUEST_RESPONSE lets an outside system influence what ISC does next.

Security Administration

This is how you lock the tenant down. The main controls:

  • User levels decide who can do what (covered in Domain 5).
  • MFA and sign-in methods, set per identity profile. Admins must always use MFA.
  • Restrict tenant access by network (IP ranges) and by geography (allow list or block list of countries).
  • Session length and lockout settings (how long sessions last, how many failures lock an account).
  • Security questions for self-service password reset.
  • API Management: API clients and PATs (above).
  • Grant support access to let SailPoint staff into your tenant temporarily, on your terms.
  • Emergency access admins as a safety net.
  • Parameter Storage for storing secrets used by integrations.
  • ISC as SAML service provider for single sign-on.

Caution from the docs: turning on "Off Network" blocking without defining a network range blocks every user in that identity profile.

Backup and Restore (Configuration Hub)

Configuration Hub backs up and restores your configuration (sources, identity profiles, roles, transforms, workflows and similar). It is not a full system backup. It does not back up identity data, and it does not include secrets or credentials.

Key facts:

  • Manual backups: up to 10 per tenant. Delete one to make room for another.
  • Automated backups: created by SYSTEM for production tenants only, managed by SailPoint, not configurable, and you cannot delete them.
  • Restore process: pick a backup, choose Prepare Draft for Deployment, review or trim the draft (optional), then deploy. Making a new draft past the limit removes the oldest.
  • Tenant connections let you move configuration between tenants, for example sandbox to production. Object mapping swaps environment-specific values.
  • The Activity Log shows the result of each deployment.
  • Some restored objects need manual follow-up to reconnect them to other objects (for example, secrets must be re-entered).
  • Config Hub has its own user levels: Config Hub Admin, Backup Admin, and Reader (view only).

Exam tip: "Roll back a bad configuration change" = restore from a backup via a draft. "Promote sandbox changes to production" = tenant connection and deployment.

Official Docs12 topics

Getting Started

Your first stop after the tenant is created: understand the setup order and learn where to watch what the tenant is doing.

Official docs: Getting Started

Getting Started in SailPoint Human Fabric

SailPoint Human Fabric is SailPoint's next-generation identity security solution. It builds on IdentityNow, and the docs cover both. Follow this order when setting up a new tenant: - Register a device. The first time you sign in through an identity provider (IdP), you must set up an external authenticator (a TOTP device). This guarantees you can still get in if you need to bypass SSO, for example with emergency admin accounts. - Add initial administrators. You need one or more emergency access administrators first. SailPoint creates one for you when the tenant is built; use it to sign in and add more. They can sign in even if connectivity (SSO) is interrupted, so they can troubleshoot and repair the site. - Load data. Data comes from sources. Use a SaaS connector if you have no virtual appliance (VA) cluster, or create a VA if you need to connect directly to on-premises sources without opening your firewall. - Create identities. Create the initial sources first (usually HR or directory sources, so their data has highest priority). Then create an identity profile, which turns a source into an authoritative source so its accounts become identities. Then load the accounts (an aggregation). - Load other account and access data. Create additional sources, load their accounts, correlate accounts to identities, and aggregate entitlements so they can be managed. - Configure security settings. Strong authentication (multifactor), network and location restrictions, lockout settings and session lengths. - Configure the cloud services you license: Access Requests, Certifications, Password Management, Separation of Duties. Related products include Access Risk Management and AI-Driven Identity Security. - Invite users so they can review certifications, manage passwords and complete tasks. Other useful facts: the Resource Center icon (top right) opens documentation, in-app product tours, the support portal, announcements and service health. You can track service status at status.sailpoint.com. To see licensing, go to Admin > System Settings > Product Licenses, which lists total permitted identities (across all lifecycle states), org name, region, and active and inactive licenses.

Managing Dashboards

After signing in you land on MySailPoint, showing your Home dashboard. There are three dashboard types: | | Home | Personal | Shared | | --- | --- | --- | --- | | Visible to users | Tiles, widgets | Not applicable | Tiles and widgets, if shared with them | | Visible to admins | Tiles, widgets | Tiles, widgets | Tiles, widgets | - Home is the default dashboard. It cannot be deleted, and its name and description cannot change. Only the Home dashboard can contain tiles, and end users cannot see widgets on it. - Personal dashboards: you can create up to 4. Add or remove widgets, and drag and drop to rearrange them. - Shared dashboards: up to 20 per tenant. Creating one generates an entitlement (this can take several minutes). Anyone given that entitlement sees all of the dashboard's widgets, whatever their user level. Grant it like any entitlement: through a requestable access profile, a role assigned automatically, or an access profile in a lifecycle state. Deleting a shared dashboard also deletes its entitlement. - Default home pages depend on user level: the Home Page (default for end users) and the Admin Overview Dashboard. Customizing them overwrites the configuration for all assigned users, including personal customizations. - Templates: Home Page Templates overwrite the default home pages; Feature Templates start a personal or shared dashboard from a set of widgets for one feature. - Caution: data segmentation does not apply to the Identity Graph widget, so users with that widget can see all access objects and identities even when segmentation is on.

Other pages in this section:

  • Audit Reports and Monitoring: How to review audit events and generate reports to prove who did what and when. Useful for compliance and troubleshooting.

Configuring System Settings

The tenant's security and branding switches: who can call the API, how long sessions last, where users may log in from, and how lockouts work.

Official docs: Configuring System Settings

Managing Lockout Settings

The tenant locks an account when a user fails the password or the multifactor (MFA) check too many times while signing in or resetting a password. Defaults: 5 wrong passwords in a row within a 5-minute window locks the account for 15 minutes. You can change all three values. - The sign-in page deliberately does not warn the user, to resist brute-force attacks. The user does get an email saying when and where the attempts happened and when the account unlocks. - After the lockout the user can retry, unlock the account or reset the password. Admins can also reset the password for them if the account may be compromised. - If the tenant restricts unlocking or password reset by country or network, those options may not work for every user. - With pass-through authentication, locking the account also locks the user's Active Directory (or other primary) account. Where: Global > Security Settings > Lockout Management. - Sign In Lockout Settings: Maximum Attempts (wrong passwords before lockout), Minutes Until Attempt Count Resets (the counting window; four failures then a five-minute break resets the count), and Minutes User is Locked Out. These apply to both password attempts and MFA verification attempts at sign-in. - Password Reset Lockout Settings: maximum attempts and lockout time for password reset attempts, including password entry and MFA during reset. - Security questions: the maximum-attempt limit does not apply to them. Failing questions at sign-in does not lock the account, but failing them while resetting a password temporarily blocks the reset, using the reset lockout settings.

Other pages in this section:

Using the Configuration Hub

The Configuration Hub (sometimes called Config Hub) backs up and moves configuration, for example from a sandbox to production. Backups are covered earlier in the guide; these pages cover the rest.

Official docs: Using the Configuration Hub

Pages in this section:

  • Working with Backups: Create and manage backups of tenant configuration so you can restore or compare later.
  • Working with Configuration Files: Uploaded or exported configuration files that hold the objects you want to deploy.
  • Reviewing Deployment Activity: History of what was deployed or restored, with results, so you can confirm or troubleshoot a deployment.
  • Using Tenant Connections: Links one tenant to another so you can move configuration directly, for example sandbox to production.
  • Viewing Scheduled Jobs: Shows the Config Hub jobs that run on a schedule, such as automatic backups.
  • Mapping Objects: Object IDs differ between tenants, so mapping tells Config Hub how an object in one tenant corresponds to one in another.
  • Using Cloud Storage: Lets backups and configuration be stored in external cloud storage instead of only inside the tenant.

Workflows

Workflows automate steps: something happens (a trigger), conditions are checked (operators) and then work is done (actions).

Official docs: Workflows

Pages in this section:

  • Building Workflows: Create a workflow in the visual editor.
  • Managing Workflows: Enable, disable, test and monitor workflows.
  • Interactive Process: Workflows that pause to wait for a person's input or approval.
  • Triggers: What starts a workflow: an event, a schedule or a manual launch.
  • Actions: The steps a workflow performs, such as sending an email or updating an identity.
  • Operators: Logic steps such as conditions and loops that control the path.
  • Templates: Ready-made workflows to start from.
  • JSONPath Expressions: The way a workflow picks values out of trigger data.

Event Triggers and Forms

Event triggers let ISC call out to your own service when something happens. Forms collect input from people inside processes.

Official docs: Event Triggers and Forms

Pages in this section:

  • Event Triggers: Call an external endpoint or run logic when a specified event occurs.
  • Forms: Build forms that gather information from users, for example in workflows.

Email Notifications

ISC sends emails for requests, approvals and more. You can customize them and control who they appear to come from.

Official docs: Email Notifications

Pages in this section:

Shared Signals Framework

A standard way for security systems to tell each other about risk events (such as a compromised session) so access can react quickly.

Official docs: Shared Signals Framework

Pages in this section:

Response and Remediation

Uses identity data to help security teams respond faster to threats.

Official docs: Response and Remediation

Pages in this section:

Collaboration Platform Integrations

Let people act on requests and approvals from chat tools.

Official docs: Collaboration Platform Integrations

Pages in this section:

  • Slack: Connect ISC to Slack.
  • Gov for Slack: The Slack variant for government environments.
  • Teams: Connect ISC to Microsoft Teams.

Activity Insights and Secure Data Sharing

Activity Insights brings in how access is actually used. Secure Data Sharing shares data safely with other platforms.

Official docs: Activity Insights and Secure Data Sharing

Pages in this section:

Glossary

Official definitions of SailPoint terms; good for the exam's vocabulary.

Official docs: Glossary

Pages in this section:

Domain 2 – Virtual Appliances (VAs)

Architecture

A Virtual Appliance is a small Linux VM that SailPoint gives you to run inside your network. Its job is to be the bridge between ISC (cloud) and systems that live behind your firewall, such as on-prem Active Directory or databases. Connectors for those sources run on the VA.

Key ideas:

  • VAs are grouped in a cluster. ISC treats the cluster as one worker pool.
  • The VA reaches out to ISC (it pulls its work from a queue). You do not open inbound holes for ISC.
  • Supported platforms: vSphere 8.0+, Hyper-V 2016+ (local), plus AWS, Azure and GCP.
  • Minimum size: 4 CPUs, 16 GB RAM, 128 GB disk.
  • Best practice: at least 2 VAs per cluster, and both a production and a sandbox cluster, so updates and failures do not cause downtime. One VA per VM host. A load balancer is not required.
  • Put VAs close to the source systems. Deploying in a DMZ is not recommended.
  • Optional cluster components (for example Privileged Access Gateway or Data Access Security collectors) need extra CPU and RAM on top of the minimum.
  • Do not install a VA in countries with data-residency restrictions (the docs name Russia and China).

Exam tip: Two VAs per cluster is the answer to almost any "how do we avoid downtime during VA updates?" question.

Connectivity

The VA only needs outbound connections. Remember these ports:

  • 443 outbound (HTTPS): all communication with SailPoint.
  • 53 outbound (DNS): name resolution. Required.
  • 123 outbound (NTP): time sync. Required (or use a local NTP server and close 123).
  • 22 inbound (SSH): admin access to the VA, recommended internal only.

More connectivity facts:

  • The firewall must allow the VA to reach required URLs, such as *.identitynow.com, *.sailpoint.com, *.launchdarkly.com, and the Flatcar update sites, plus AWS services (S3, SQS, DynamoDB, container registry). You must always allow the us-east-1 versions and your tenant's own region.
  • If your firewall cannot allow domain names, use the network tunnel VA configuration instead, which connects to a fixed set of SailPoint IPs on 443.
  • Deep packet inspection (TLS inspection): VAs reject untrusted certificates, so install your private root CA on the VA.
  • An optional HTTP proxy is supported.
  • Do not place sources in SailPoint-reserved ranges: 10.255.255.241/28 (all VAs) and 172.16.0.0/22 (network tunnel VAs), or traffic will not route.
  • Target systems have their own ports (for example LDAP). The VA must be allowed to reach them too.

Monitoring

You watch VA health in the ISC admin UI (VA and cluster status, last communication) and through the VA observability features. You can also configure system health notifications to email admins when something is wrong.

Exam tip: Third-party monitoring agents installed on the VA are not supported.

DNS

The VA needs working DNS because it must resolve both SailPoint's hostnames and your internal source hostnames. It is required to point the VA at your internal DNS servers. If a source test fails with "host not found", suspect DNS first.

Firewall Rules

This is the checklist from the Connectivity section turned into rules: outbound 443, 53 and 123 (or local NTP) to the right destinations; inbound 22 only from inside; allow the listed URLs; allow the ports the target systems need. Note that allow-listing by raw IP address of SailPoint services is not supported because those IPs change. Use domain names or the network tunnel option.

Troubleshooting

Work from the bottom up:

  1. VA not reporting or shows unhealthy: check outbound 443 and DNS, then check that the clock is correct.
  2. Time drift: a VA with the wrong time can fail to communicate. Check with timedatectl status. To use a local NTP server, edit /etc/systemd/timesyncd.conf (remove the # on the NTP= line and add your servers), then restart with sudo systemctl restart systemd-timesyncd. Do this on every VA before closing port 123.
  3. Source connection fails: test from the VA's network position. Is the target reachable? Is its port open? Do DNS and credentials work?
  4. Update-time outages: you probably only have one VA in the cluster.
  5. TLS errors behind a proxy or inspection device: missing root CA trust.
  6. Source unreachable only for certain sources: the source's own ports may be blocked, not SailPoint's.
Official Docs1 topics

Virtual Appliances

A VA is the cluster inside your network that lets ISC reach on-premises systems. This ties back to Domain 2.

A virtual appliance (VA) is a Linux-based virtual machine that connects your tenant to your on-premises applications and sources. (Private clouds count as on-premises.) It is provided as a virtual disk image, runs on your infrastructure, and SailPoint maintains, patches and upgrades its software. SailPoint never connects directly to the VA. Each VA makes continuous outbound-only calls to the cloud to poll the cluster queue for work (aggregation, provisioning), install patches and update images. To use VAs you must supply the hardware or hypervisor, make sure connectivity to the cloud works, and monitor VA health.

Official docs: Virtual Appliances

Getting Started with Virtual Appliances

Plan carefully, because the VA is critical. The person doing this must understand your virtualization platform and network security. Facts to know: VAs run in UTC and this cannot be changed. Adding users, key store access and root access are not supported. The VA runs Flatcar Linux; Flatcar updates are tested in a sandbox for one week before VA release. IdentityIQ organizations need extra configuration. Process: 1. Review system and network requirements and best practices. 1. Pick a deployment option: local with vSphere, local with Hyper-V (both need a static network), or cloud with AWS, Azure or GCP. Also plan high availability and disaster recovery. 1. Pick a network configuration. All traffic is outbound only; nothing inbound from outside is needed. Options: Standard, HTTP Proxy (all HTTP/HTTPS routed through a proxy), or Network Tunnel (limits outbound connections; use only if your firewall cannot allow host names). Optional: TLS to sources, Password Interceptor (Active Directory password changes propagate to SailPoint), and a local NTP server if you cannot open outbound port 123. 1. Deploy, configure, then monitor and maintain. Troubleshooting: restarting the VA cluster is almost always the best first action. If that fails, stand up a replacement VA. Best practices: place VAs close to their sources (same availability zone or region as your VPN gateways); keep a 1:1 VA-to-VM ratio and spread cluster members across different servers or availability zones; to switch platform or deployment method you must create new VAs, because migrating existing ones is not supported.

Deploying Virtual Appliances

Pick the section for your platform, then continue to "Starting a New Virtual Machine". - vSphere: download and unzip the package and copy it to your platform. - Hyper-V: use the sailpoint-va.vhd file; choose Generation 1 and an External virtual switch. If using Hyper-V, disable the waagent service to avoid DNS and routing problems. - AWS: open a support ticket for an AMI ID (give your AWS account number and region). Open port 22 from your IP range, pick an instance size from the requirements, and set the Instance Metadata Service to accessible with hop limit 2. - Azure: the extracted image is about 132 GB; upload it to a storage container with the Azure CLI, create a managed disk, then create the VM (example size Standard_B4ms). The network security group must allow port 22. - GCP: import the VA disk as a non-bootable disk, then create an instance from the custom image with a 128 GB disk. Starting the VM: sign in as sailpoint, change the password at once (if lost, a new VA must be created). Local deployments need a static IP set in /etc/systemd/network/static.network (NIC name, DNS, address with CIDR, gateway), then reboot. Creating a cluster (Admin > Connections > Virtual Appliances > Create New): give a unique name and description, choose a time zone (it sets the GMT offset for scheduled aggregations), and choose Standard unless you use IdentityIQ, in which case choose IAI Harvester. The cluster type cannot be changed later. Optionally enable debugging (24 hours of verbose logging; otherwise log files roll at 512 MB). Cluster components include the Cloud Connector Gateway (on by default), Privileged Access Gateway, and Data Access Security collectors. Then add VAs: download the image, set the passphrase, get the pairing code and pair. High availability and disaster recovery (each source belongs to one cluster; VAs poll that cluster's queue): - All VAs running: one cluster with VAs in primary and DR datacenters. No action needed on failover and everything is used, but latency can be an issue. - Switch clusters: a primary cluster and a DR cluster, both powered on and updated. No latency impact, but after a disaster you must repoint sources and re-enter source credentials. - Standby reactive: standby VAs are prepared but not in a cluster. Slower recovery and depends on their readiness. Do not deploy VAs in the DMZ. Reasons: security (each VA holds a 2048-bit RSA private key used to decrypt credentials), proximity to sources (latency-sensitive APIs), and connectivity (you would open more internal ports).

Configuring Virtual Appliances

Three network options: - Standard (default): the VA reaches SailPoint and other endpoints directly through the firewall. No extra setup beyond meeting network requirements and adding the required URLs to your allow list. SailPoint reserves the IP range 10.255.255.241/28; sources in that range will not route correctly. - HTTP proxy: all HTTP/HTTPS traffic (VA communication, updates, internal or external) goes through the proxy, including traffic to external sources such as Salesforce or Workday. It cannot be combined with the network tunnel. Proxy authentication works only with basic authentication in the connection string, otherwise the connection is unauthenticated. You set it in a proxy.yaml file in /home/sailpoint/ (https_proxy and http_proxy lines), and can exempt hosts with no_proxy: host1|host2. In a cloud environment, avoid routing to the metadata API (usually 169.254.169.254). - Network tunnel: for firewalls that cannot allow domain names. Pairing steps (HTTP proxy example): start the image, sign in as sailpoint and change the default password immediately, run va-bootstrap set-passphrase, run va-bootstrap pair to get a code, enter the code in the UI within 4 hours and select Pair, then wait about 30 minutes until the status shows Connected. The passphrase must be identical for every VA in the cluster, cannot start with a special character, and cannot contain !, /, , or spaces. It is stored encrypted (shown with leading ::::). Other settings: - TLS: recommended between VAs and sources that support it. Enable it on the source (Admin > Connections > Sources > Source Setup > Use Transport Layer Security). The certificate is copied to the VA cluster automatically. Active Directory has TLS checkboxes for Forest, Domain, IQ Service and Exchange. - FIPS (FedRAMP): configured per VA at the Linux kernel level and cannot be reversed. To undo it you must create new VAs from a fresh image. - hosts.yaml: some connectors need a host entry. Create it in /home/sailpoint/ with precise indentation (IP line, then fully qualified host name and short host name), then run sudo systemctl restart charon.

Managing Virtual Appliances

  • Updates are managed by SailPoint. Clusters do rolling updates and reboots one VA at a time, so you need at least 2 VAs per cluster. They cannot be skipped or delayed and there is no advance notice (sandbox gets them about a week earlier). Long-running aggregations may be interrupted. If any VA in a cluster is not connected, no updates are made to any VA in that cluster. SailPoint supports only N-2 major releases. Busy processes are updated later, but an excessively busy process can be overridden for security or critical fixes. - Monitoring options: email notifications, the Admin dashboard Clusters tile, the Virtual Appliance Clusters page, cluster details, edit and view VA pages, and third-party tools. - Cluster badges: VA Update in Progress, Empty Cluster, Only 1 VA in Cluster, Inactive VA, VA Did Not Update (restart the cluster), All VAs Inactive. - VA status: Connected, Update in Progress, Configuration Incomplete (delete and retry), VA Did Not Update, Inactive State (contact your network admin). - Warnings and errors: certificate expired or expiring within 30 days; disk over 80% (warning) or 90% (error), usually from debug logs; memory 12-hour average over 80% or 90%; network error (check required URLs); OS update needs reboot or failed; service instability when a container restarts more than 10 times in 30 minutes. - Process status: OK, Busy, Error. - Connect or disconnect a source: edit the source and pick a different VA cluster in Base Configuration. A VA that is the only one in its cluster and still attached to a source cannot be deleted. - Time zone: cluster setting that controls aggregation schedule offsets. - Maintenance: change the VA password with passwd and reboot. Restart a cluster from the cluster card menu. Edit a cluster to change name, description, time zone, debugging, VAs or components (component changes are for Standard clusters only). Delete a VA, then shut down its instance on your platform or performance may degrade. Delete a cluster only after disconnecting it from sources and deleting its VAs. - Recovering from failure: create a new cluster with at least 2 VAs, note the sources on the failed cluster (Details > Connections), repoint each source, verify, then delete the failed cluster. Never move or migrate existing VAs. - Manual updates and your own OS are limited-availability options requiring legal addenda and extra responsibility from you. Manual updates still require applying security fixes immediately; falling more than 2 versions behind means "Out of Support". A customer-provided OS must be hardened (CIS benchmarks; STIG for FedRAMP), patched at least weekly, and scanned for vulnerabilities.

Virtual Appliance Observability

VAs can export metrics and logs to third-party tools. - Metrics use an OpenTelemetry agent (otel_agent). Supported tools sharing a common configuration: Datadog, Dynatrace, Grafana Labs, Honeycomb, New Relic and SignalFX. Enable it by adding enableOTELAgent: true to /home/sailpoint/config.yaml, start it with sudo systemctl start otel_agent, then set OTLP_ENDPOINT and OTLP_API_KEY in /home/sailpoint/otel.env and restart. If you leave those empty, metrics go to your SailPoint tenant instead. Check /home/sailpoint/log/otel_agent.log for errors. Metrics include CPU load, filesystem usage, memory utilization and network I/O, plus CCG health metrics. - Logs go to Splunk HTTP event collector, CloudWatch Logs or Datadog. Create a host-logging.yaml file in /home/sailpoint listing each logger (type is splunk_hec, cwlogs or datadog) with its keys, and optionally enableSailPointLogging: true to include SailPoint container logs as well as the OS journal. - Common problems: a wrong or over-long API key value (only the key itself belongs in OTLP_API_KEY), a wrong endpoint URL (the agent cannot detect the backend), or missing variables in otel.env.

Other pages in this section:

Domain 3 – Identity and Lifecycle

Identity Profiles

An identity profile turns an authoritative source (usually HR) into identities. Every account on that source becomes an identity.

What an identity profile controls:

  • Which source is authoritative.
  • Sign-in and security settings for its identities (sign-in method, MFA, invitations, password reset methods, network/geography blocking).
  • Mappings for identity attributes.
  • Lifecycle states and the access tied to them.

Key rules:

  • One identity belongs to one identity profile only. If someone appears in two authoritative sources, the higher-priority profile wins. Priority follows creation order (first profile is 10, next 20, and so on) and can be changed with an API call.
  • Required attributes: User Name (uid), Work Email (email) and Last Name (lastname). If an account lacks them, or the uid is a duplicate, ISC raises an identity exception (downloadable from the profile) and the person shows as an incomplete identity. Fix the data in the source, then aggregate again.
  • After you change mappings, use Preview to test, then Apply Changes to reprocess.
  • Deleting an identity profile makes the source non-authoritative and deletes its identities (their accounts become uncorrelated). Sources owned by those identities block deletion.
  • You cannot create or delete an identity profile while an aggregation is running.

Exam tip: Sign-in methods include username and password, directory connection (pass-through authentication), and MFA.

Mappings

Mappings say where each identity attribute gets its value. For each attribute you choose a source, a source attribute, and optionally a transform. Different profiles can map differently, and an attribute can come from a different source than the authoritative one (for example email from Active Directory while everything else comes from HR).

Special attributes to remember:

  • Lifecycle State must be mapped if you want lifecycle states to work.
  • Manager must be mapped, plus manager correlation configured on the source, if you use manager approvals or manager certifications.
  • Avoid the characters * ( ) & ! . in attributes used as username or sign-in.
  • Unmapping an attribute: set its source to None.

Transforms

A transform changes a source value before it is stored. Examples: make text lowercase (ToLower), uppercase, strip accent marks, convert a phone to E.164 format, convert country to the ISO 2-letter code.

  • Simple transforms are built in. Complex transforms chain several operations (for example, calculate a lifecycle state from a start date) and are uploaded through the API.
  • Rules are code-based and more powerful, but SailPoint Services must review them before use. Transforms do not need that review. Prefer a transform when possible.
  • A multi-value attribute fed through a transform keeps only its first value.
  • International phone numbers need the E.164 transform on the work phone attribute.

Attributes

ISC ships default identity attributes (for example city, department, email, firstname, lastname, manager, title, uid, startDate, endDate, location, costCenter). You can add custom attributes.

Important behaviors:

  • A custom attribute you add appears in all identity profiles (you only map it where you need it).
  • Deleting a custom attribute removes it from all profiles, and you must reprocess each profile. It can break roles whose membership uses it, SAML attribute maps, transforms/rules, lifecycle calculations and certification filters.
  • Do not delete default attributes.
  • Account attributes live on source accounts (defined in the account schema). Identity attributes live on the identity. Mapping connects the two.

Lifecycle States

A lifecycle state describes where a person is in their time at the company. Each state can change their access automatically.

Defaults for new identity profiles: pre-hire, active, leave of absence, terminated, archived. You can add more.

What a state can do:

  • Remove all access (on by default for terminated and archived). Birthright access and access profiles listed on that state are kept.
  • Enable, disable or delete source accounts (all sources, specific sources, or all except some). Delete is irreversible and only works with the long-term inactive identity state.
  • Grant access profiles that apply while the person is in that state. They are revoked when they leave the state unless the next state also grants them.
  • Send notifications to the manager, all admins, or chosen emails.
  • Set the identity state: Active, Inactive (short-term) or Inactive (long-term). Only Active identities show up in Request Center and team lists.

How identities get a state:

  • Each identity has a Lifecycle State attribute. Its value must exactly match the technical name of a state. Matching is case-sensitive (active is not Active).
  • Admins can also set it manually. A manual value lasts only until the source value changes.
  • Common errors: not set (attribute unmapped or empty), not valid (no matching state), case mismatch.

Other facts: states are disabled by default, so enable each one. An identity can be in one state at a time. Actions run once and are not a persistent retry. Retryable provisioning failures are retried once per hour, up to 3 times. A state can also trigger an automatic invitation when someone moves from pre-hire to active.

JML Processing (Joiner, Mover, Leaver)

JML is the standard identity story:

  • Joiner: HR account appears, aggregation creates an identity, lifecycle state becomes pre-hire or active, birthright roles and the state's access profiles provision accounts and access.
  • Mover: the person's attributes change (department, job title, manager). Identity processing re-evaluates role membership criteria, so old access is removed and new access added.
  • Leaver: HR marks them terminated. The lifecycle state changes, access is removed, accounts are disabled (later maybe deleted).

Identity processing runs when events happen and on a schedule. Manual Apply Changes forces it. If a profile shows Needs Processing, changes are saved but not yet applied.

Exam tip: Most JML questions are really lifecycle state or role membership criteria questions in disguise.

Official Docs5 topics

Loading Identity and Access Data

This is the data pipeline: sources supply accounts, schemas describe them, correlation ties accounts to people, and identity processing builds the final identity. If data looks wrong, walk through these steps in order.

Official docs: Loading Identity and Access Data

Pages in this section:

  • Updating Emergency Access Admins: Emergency access admins are named admins who can still get in if your normal sign-in path (such as SSO) is unavailable. Keep this list current.
  • Configuring Sources: How to connect a system (AD, Salesforce, a database, and so on) so ISC can read and write its accounts.
  • Loading Account Data: Account aggregation: pulling account records from a source into ISC, either manually or on a schedule.
  • Creating Identity Profiles: An identity profile ties an authoritative source to identity attribute mappings and lifecycle states. It decides how a person's identity is built.
  • Configuring Multifactor Authentication: Choose which extra verification methods users need when signing in to ISC, to protect against stolen passwords.
  • Managing Account Schemas: The schema lists the attributes a source's accounts have, and marks which attribute is the account ID, display name and entitlement. Wrong schema means wrong data.
  • Assigning Source Accounts to Identities: Correlation: matching each source account to the right identity, usually by comparing an account attribute to an identity attribute such as email or employee ID.
  • Configuring Manager Correlation: Tells ISC how to work out a person's manager, by matching a manager value on the account to another identity. Approvals and certifications depend on it.
  • Processing Identity Data: Identity processing recalculates identities after new data arrives: attributes, lifecycle state, roles and provisioning. Run it after changing mappings.

Managing Users

Everything about the people in the tenant: inviting them, resetting credentials, viewing identities and accounts, and handing work over.

Official docs: Managing Users

Pages in this section:

Identity Graph

A visual map of how identities, accounts and access connect, to make complex access easier to understand.

Official docs: Identity Graph

Pages in this section:

Machine Identity Security

Governs non-person identities such as service and application accounts, with owners and reviews like people get.

Official docs: Machine Identity Security

Pages in this section:

Agent Identity Security

Brings AI agents under identity governance, so each has an owner and controlled access.

Official docs: Agent Identity Security

Pages in this section:

Domain 4 – Provisioning

Provisioning Triggers

Provisioning means making a change on a source (create, update, enable, disable, delete an account, or add and remove entitlements). Things that cause provisioning:

  • An access request that gets approved.
  • A role assignment (automatic through membership criteria, or by request).
  • A lifecycle state change.
  • Attribute synchronization (identity attribute changes pushed to account attributes).
  • Manual admin actions (for example setting a lifecycle state, or removing an account).
  • A certification revocation.

To create accounts, a source needs a create-account provisioning policy (the "create profile"), which defines which attributes and values are sent. Without it, ISC can't create accounts there.

Channels

The blueprint says "Channels" without defining it. In practice it means how a change travels to the target:

  • Direct through a connector, either a cloud connector or one running on a VA. This is automatic.
  • Manual provisioning, where ISC creates a task for the source owner to do by hand because the system has no write-capable connector.
  • Through a ticketing integration that creates a ticket for another team.

Different sources support different operations (some can create but not delete, some cannot disable). Check what the connector supports before designing lifecycle actions.

Heads-up: this term is interpretive. Check the official exam guide to confirm the exact meaning.

Connector Logs

When provisioning or aggregation misbehaves, you follow the evidence trail:

  • Account Activity and provisioning events show what was requested and the outcome.
  • Search > Events shows audit events.
  • Aggregation history on the source shows counts, warnings and errors.
  • For VA-based sources, connector and VA logs capture the detailed connector errors (typically gathered with SailPoint Support).

Failures

Provisioning failures fall into two groups:

  • Retryable errors (temporary: network blip, source busy). ISC retries automatically.
  • Non-retryable errors (bad data, missing permission, duplicate account name, password policy violation, attribute not allowed). These need a human fix.

Typical causes: the service account behind the source lacks rights, a required attribute is missing in the create policy, the VA or cluster is down, the account already exists, or the target rejects a value.

Troubleshooting

A reliable sequence:

  1. What happened? Look at Account Activity or events for the request.
  2. Is the source healthy? Run a connection test, check VA status.
  3. Is the data valid? Compare the provisioning policy values with what the target accepts.
  4. Are permissions OK? Confirm the connector's service account can perform the action.
  5. Fix and retry, or retrigger by reapplying the lifecycle state or reprocessing the identity.
  6. Verify: the next aggregation confirms the account state in ISC.

Exam tip: Remember that disabled-by-default lifecycle states, missing create policies, and a case-mismatch in the lifecycle attribute are classic reasons that "nothing provisioned".

Official Docs2 topics

Password Management

Password Management simplifies password administration across your sources and applications and enforces strong, consistent policies. For example, if several apps share one Active Directory password, a change can update them all at once. Use it to set password policies per source, change a shared password across sources with sync groups, and set advanced options such as a password dictionary and URL access. Before enabling it, set up access applications for the systems whose passwords users may reset.

Official docs: Password Management

Pages in this section:

Provisioning

Provisioning is how ISC creates, changes and removes accounts and access in sources. Pair these pages with Domain 4.

Official docs: Provisioning

Pages in this section:

Domain 5 – Access Management

Think of access as building blocks, from smallest to largest: Entitlement → Access Profile → Role.

Entitlements

An entitlement is a single permission or membership on a source: an Active Directory group, a Salesforce profile, a database role. Entitlements are loaded by entitlement aggregation, which is separate from account aggregation. You need them loaded before you can build anything on top of them.

In ISC you can add helpful information to an entitlement: an owner (used for approvals), a description, and flags such as requestable and privileged. The value itself still comes from the source. An entitlement can be requested directly only if it is marked requestable.

Access Profiles

An access profile is a bundle of entitlements from one source. Use it to describe a job-sized chunk of access on that system, for example "AD – Finance Shared Drives".

Key facts:

  • Entitlements in a profile must all come from a single source.
  • Every access profile needs an owner.
  • You decide whether it is requestable, who approves it, and whether revoking it needs approval.
  • If a person has several accounts on that source, the multiple account option decides which account receives the access.
  • Access profiles can be placed inside roles and attached to lifecycle states.

Roles

A role is a bigger bundle: it can hold access profiles and entitlements from many sources. It also has membership, which says who gets it.

Two main ways people get a role:

  • Automatically through membership criteria (for example department = Finance). This is how birthright access works. ISC re-checks during identity processing, so people gain the role when they match and lose it when they stop matching.
  • By request (a requestable role, with approvals).

An identity list (hand-picked members) is also possible. Roles can be marked requestable, can require approval, and have an owner. A role must be enabled to work.

Exam tip: "All new Finance employees need the same access automatically" = role with membership criteria (birthright). "Employees can ask for extra access" = requestable role or access profile.

User Levels

User levels are the admin permission sets inside ISC. Know them cold:

  • Org Admin (ORG_ADMIN): everything. Do not pair it with other elevated levels, because overlaps can unexpectedly reduce its rights.
  • Cert Admin: manages certification campaigns.
  • Helpdesk: helps users (for example password reset and unlock, viewing identities). It cannot revoke access items or manually set lifecycle states.
  • Report Admin: runs and manages reports.
  • Role Admin / Role Sub-Admin: manage roles. A sub-admin is limited to roles they own or via governance groups.
  • Source Admin / Source Sub-Admin: manage sources and related objects. A sub-admin is limited to sources they own or are assigned to.
  • Cloud Gov, Config Hub, Identity Graph, Access Intelligence levels: specialist levels for those features.
  • End User: everyone, with basic self-service.

Rules:

  • Levels are cumulative. You get the combined permissions of everything granted.
  • These pairs cannot be granted together: Role Admin + Source Sub-Admin; Role Sub-Admin + Source Admin; Role Sub-Admin + Role Admin; Source Sub-Admin + Source Admin.
  • Users cannot give themselves levels. Only admins can (or workflows and requests you build).
  • You can govern user levels as entitlements through the built-in IdentityNow source, so they can be requested and certified. A system setting decides whether non-Org-Admins (Role and Source admins) may manage those entitlements, which adds risk.
  • Custom user levels exist for finer least-privilege control.
  • API keys and PATs can never exceed the user's level.

Role Assignment

Role assignment is how a role ends up on an identity:

  1. Automatic: membership criteria matched during identity processing.
  2. Requested: a user asks, approvers approve.
  3. Manual: an admin adds the role to an identity.

Once a role is assigned, ISC provisions its access profiles and entitlements. If the person later stops qualifying (for a criteria-based role), the role and its access are removed, unless the same access is still granted another way (another role, a lifecycle state, a direct request).

Changing criteria or attributes means identities need reprocessing before assignments update. A deleted or renamed attribute used by criteria is a common cause of roles suddenly not assigning.

Official Docs3 topics

Managing Access

Entitlements, access profiles and roles are the building blocks. The pages below add descriptions, metadata and newer features on top.

Official docs: Managing Access

Pages in this section:

User Levels

User levels decide what each admin can do in the console. Custom levels let you give someone just the permissions they need, which supports least privilege.

Official docs: User Levels

Pages in this section:

Data Segmentation

Data segmentation limits which identities, sources and access items a given admin can see, so different teams or regions only manage their own data.

Official docs: Data Segmentation

Pages in this section:

Domain 6 – Governance

Governance is the "keep it safe and provable" part: people request access, approvers decide, reviewers re-check, and policies block bad combinations.

Access Requests

Users shop for access in the Request Center. They can request for themselves, or for others if Requests for Others is enabled. They can request roles, access profiles and entitlements that are marked requestable.

Things an admin configures:

  • Which items are requestable, and any approval steps and comment requirements per item.
  • Global approval settings (defaults such as reminders and escalation).
  • Request segments to limit who sees which items.
  • Requests for machine identities where applicable.
  • SoD checks: if the request would cause a conflict, the requester and approver are warned.

After approval, ISC provisions the access, then verifies it on the next aggregation.

Approvals

Approvals are the "yes or no" steps in a request. Each item chooses its approval scheme, for example manager, source owner, owner of the access profile, role or entitlement, a governance group, or a workflow-driven approval. You can chain steps (for example manager then source owner), and each must approve in order.

Useful supporting features:

  • Approvals Administration: admins can see and reassign stuck approvals.
  • Work reassignment: an approver who is away can delegate their approvals, certifications and tasks to someone else.
  • Reauthentication: require approvers to confirm identity again before approving.
  • Adaptive approvals: AI-assisted suggestions to speed approvals.
  • Dynamic approval trigger: an outside system picks the approver (REQUEST_RESPONSE trigger).
  • Notifications and reminders keep requests moving.

Exam tip: "Nobody approved the request and the approver left" = work reassignment or Approvals Administration.

Certifications

A certification campaign is a periodic access review: reviewers confirm that each person's access is still appropriate.

Types you should know:

  • Manager campaign: managers review their direct reports' access.
  • Source owner campaign: owners review access on their source.
  • Search campaign: reviews exactly the access found by a saved search.
  • Role composition campaign: reviews what a role contains and who has it.

How it flows:

  1. Admin (often Cert Admin) creates the campaign, chooses scope, filters (exclusions) and deadlines.
  2. Reviewers see items and decide Approve (keep) or Revoke (remove), or reassign to someone else.
  3. Reminders and escalations chase late reviewers.
  4. The campaign is completed. Revoke decisions result in provisioning requests to remove access.
  5. Status reports and history serve as audit evidence.

Exam tip: Certifications are detective (they find access that should not exist). Approvals and SoD prevention are preventive.

Policies

Policies are rules you want enforced. In ISC the key policy type is Separation of Duties, plus general governance policies. A related feature, Policy Center, covers just-in-time access policies.

SoD (Separation of Duties)

SoD means nobody should hold a dangerous combination of access, for example "create vendor" and "approve payment".

How an SoD policy is built:

  • Two lists of access: List A and List B. If one identity has access in both lists, that is a violation.
  • Access can be entitlements, and more recently roles and access profiles can be used too. Through the API, each list holds up to 50 entitlements.
  • A policy owner (the subject matter expert) and a violation owner (who handles violations).

Preventive vs detective:

  • Preventive: warnings appear during access requests. Admins can also block all requests that cause a conflict under Admin > Global > System Settings > Feature Settings > Access Requests, or configure an individual policy to prevent them.
  • Detective: violation reports, policy subscriptions (emailed reports) and certifications reveal existing violations.

Gotchas:

  • A warning does not automatically stop approval unless blocking is configured. An approver may still approve.
  • Requesting both conflicting items in one request may not be flagged beforehand, because neither is held yet.
  • Disabled policies do not appear in bulk violation reports.
  • Violation owners can remove the access, allow it with a documented control, or reassign the violation.
Official Docs5 topics

Access Requests

Admin settings that decide what can be requested, by whom, and how approvals work. See Domain 6 for the basics.

Official docs: Access Requests

Pages in this section:

Certifications

A certification campaign asks reviewers to confirm that people should keep their access. These pages cover how admins start, tune and finish campaigns.

Official docs: Certifications

Pages in this section:

Separation of Duties

SoD policies stop one person from holding a risky combination of access, such as creating and approving payments.

Official docs: Separation of Duties

Pages in this section:

Policy Center

Policy Center holds newer policy types that control when and how privileged or sensitive access is granted.

Official docs: Policy Center

Pages in this section:

Adaptive Approvals

Adaptive approvals adjust the approval path based on context such as risk, instead of using one fixed chain for every request.

Official docs: Adaptive Approvals

Domain 7 – Sources

Aggregation

Aggregation means loading data from a source into ISC. There are two flavours: account aggregation and entitlement aggregation. Run them on a schedule or manually.

Key facts:

  • Normal aggregations are optimized. ISC skips accounts that have not changed. That is fast, but it means ISC won't re-evaluate unchanged accounts.
  • An unoptimized aggregation (optimization disabled) reprocesses every account. Use it after changing correlation, schema or similar settings, or to fix stuck correlations.
  • Native change detection spots changes made directly in the source (outside ISC) and can raise events.
  • Account filters let you leave out accounts you don't want (for example service or terminated accounts).
  • Reset source deletes all of that source's accounts and entitlements so you can reload. Handle with care.
  • Check Aggregation History for counts, duration and warnings.
  • Order of operations when onboarding: configure the source and correlation first, aggregate the authoritative source to create identities, then aggregate the other sources.

Correlation

Correlation is matching an account to an identity. You configure it per source, usually by matching one identity attribute to one account attribute (for example identity employeeNumber equals account employeeId). A rule can be used for harder cases.

Key facts:

  • Configure it before the first aggregation.
  • Accounts that match nothing become uncorrelated accounts. Find them with the Uncorrelated Accounts report, fix the data on the source and aggregate again, or correlate manually.
  • Changing correlation on an already-aggregated source requires an unoptimized aggregation.
  • A manual correlation can survive later aggregations, so don't be surprised when an account stays attached.
  • Manager correlation is a separate configuration that links the manager value on an account to a manager identity.
  • If an account matches more than one identity, correlation fails to pick one.

Exam tip: "Accounts loaded but not attached to people" = correlation. First check the config, then run an unoptimized aggregation.

Connectors

A connector is the code that talks to a particular type of system (Active Directory, Entra ID, Workday, Salesforce, JDBC databases, delimited files, web services and more).

  • SaaS (cloud) connectors run in the cloud and talk directly to cloud apps.
  • VA-based connectors run on your Virtual Appliance so they can reach on-premises systems. They are assigned to a VA cluster.
  • Each source defines its connection settings and credentials, an account schema, correlation, provisioning policies, and what the source is allowed to do (aggregate, create, disable, and so on).
  • Sources have an owner and often a governance group, which feed approvals and certifications.
  • Some VA-based sources can be migrated to SaaS connectors.
  • Always test the connection after changes.

Accounts

An account is a login on a source. The account schema lists its attributes and marks special ones: the account's unique ID (native identity), the display name, and the attribute that holds entitlements.

Account states to know: enabled, disabled, locked, correlated or uncorrelated, and machine accounts (not owned by a person). Admins and helpdesk can unlock or enable accounts, and account deletion requests can be reviewed and approved.

Entitlements

Entitlements on a source are described by the entitlement schema (for example "group") and are loaded by entitlement aggregation. You can define entitlement types when a source has more than one kind (groups, roles, permissions).

If your access profile or request catalog is missing entitlements, the usual cause is that entitlement aggregation was never run or the schema is not set up for it.

Source Errors

Common problems and where to look:

  • Connection test fails: wrong or expired service-account password, blocked port, DNS issue, TLS or certificate trust.
  • No healthy VA in the cluster: VA offline, time drift, firewall change.
  • Aggregation errors or warnings: timeouts, schema or attribute mismatch, malformed or duplicate data. Open the aggregation details.
  • Identity exceptions on an authoritative source: missing uid, email or last name.
  • Accounts not correlating: wrong attribute mapping, case or format differences, changed config without an unoptimized run.
  • Source went quiet: schedule disabled, credentials changed, source system down.

A good troubleshooting order: connection → credentials → network/VA → schema → data → correlation.

Official Docs3 topics

Loading Entitlement Data

Entitlements are the permissions inside a source. They are loaded separately from accounts, and you need them loaded before they can be requested, certified or put in access profiles.

Official docs: Loading Entitlement Data

Pages in this section:

  • Creating and Managing Entitlement Types: Defines the kinds of entitlement a source has (for example groups or roles) so they are loaded and shown correctly.
  • Aggregating Entitlements: Entitlement aggregation loads the list of entitlements from the source. Account aggregation alone does not bring in entitlement details such as descriptions.

Managing Sources

Extra source features for detecting changes and managing source settings.

Official docs: Managing Sources

Pages in this section:

Managing Multi-Host Groups

A multi-host group treats several similar systems (for example many servers or instances) as one logical source, so you configure aggregation, schemas and provisioning once instead of per host.

Official docs: Managing Multi-Host Groups

Pages in this section:

Domain 8 – IGA Fundamentals

IGA

Identity Governance and Administration answers three questions: Who has access to what? Should they have it? Can we prove it?

It rests on three pillars, which match ISC features:

  • Identity administration: creating and maintaining identities and their lifecycle (identity profiles, JML).
  • Access management and provisioning: giving and removing access (roles, requests, provisioning).
  • Governance: reviewing and controlling access (certifications, SoD, policies, audit).

Core principles: least privilege (only what is needed), birthright access (baseline access for a job), and role-based access control (RBAC). RBAC grants access by role. ABAC grants it by attributes (department, location). ISC role criteria blend both.

Compliance

Regulations and frameworks such as SOX, HIPAA, PCI DSS, GDPR and ISO 27001 expect organizations to prove control over access. Auditors usually ask for:

  • Who has access (reports, search).
  • Periodic review (certification campaigns).
  • Preventive controls (approvals, SoD).
  • Audit trail (events and history).
  • Timely removal when people leave (lifecycle states).

Authentication

Authentication proves who you are. Factors are something you know (password), have (phone or authenticator app) or are (fingerprint). In ISC:

  • Sign-in method is chosen per identity profile: ISC username and password, directory connection (pass-through authentication), or MFA.
  • Password management adds password policies, sync groups (keep one password across several sources), and self-service reset methods such as security questions, email or authenticator, optionally requiring two methods.
  • Lockout and session length settings protect against abuse.

Authorization

Authorization decides what you may do once you are in. In ISC that is the user level (what you can do in the admin console) and the entitlements, access profiles and roles (what you can do in connected apps). Authentication comes first, authorization second.

Federation

Federation means one system trusts another to vouch for a user, so people use a single identity across organizations or applications.

  • Identity Provider (IdP): authenticates the user and issues proof.
  • Service Provider (SP): the application that accepts that proof.
  • Common protocols: SAML 2.0 (XML assertions, common for enterprise SSO), OpenID Connect (login layer on top of OAuth 2.0), and OAuth 2.0 (delegated authorization, not login).
  • In ISC, you can configure the tenant as a SAML service provider so users sign in through your corporate IdP.

MFA and SSO

  • MFA requires at least two factor types. In ISC, admins must always use MFA, and you can require it for other identity profiles through authenticator apps such as Google Authenticator or Duo Mobile. Password reset can also demand two methods.
  • SSO lets a user sign in once and reach many apps. ISC supports SSO sign-in through SAML, and also lets you govern access on SSO providers so the apps behind them are requested and certified like any other access.
  • Reauthentication for approvals adds a step-up check on sensitive actions.
Official Docs7 topics

AI Overview

Assistants and recommendations that help admins and reviewers decide faster.

Official docs: AI Overview

Pages in this section:

Application Onboarding

Speeds up connecting new apps by discovering them and recommending how to connect.

Official docs: Application Onboarding

Pages in this section:

Access Insights and Access Modeling

Insights find unusual access; modeling helps design better roles.

Official docs: Access Insights and Access Modeling

Pages in this section:

IdentityIQ and AI-Driven Identity Security

Lets IdentityIQ (the on-premises SailPoint product) use the same AI features.

Official docs: IdentityIQ and AI-Driven Identity Security

Pages in this section:

SailPoint Agentic Fabric

Finds and governs non-human identities, especially AI agents, applications, credentials and MCP servers. Onboarding connects identity providers, sensors, sources and security tools, then you review and activate. Afterwards you manage agents and related objects.

Official docs: SailPoint Agentic Fabric

Pages in this section:

SailPoint CIEM

CIEM (Cloud Infrastructure Entitlement Management) finds and governs permissions in cloud platforms. For each of AWS, Azure, GCP and Okta the pattern is the same: configure the cloud side, connect it to SailPoint, then manage entitlements.

Official docs: SailPoint CIEM

Pages in this section:

Privilege

Features that reduce standing privileged access: automating privileged tasks, granting privilege only on demand, classifying what is privileged, and showing effective privilege.

Official docs: Privilege

Pages in this section:

Quick Reference: Numbers and Facts to Memorize

TopicFact
Config HubMax 10 manual backups; automated backups are production only, SYSTEM-created, not configurable; no secrets or identity data; restore via draft
PATs10 per user; default 6 months; blank = never expires; restore expired up to 3 months; scope changes up to 30 min; bulk update 25
VA size4 CPU, 16 GB RAM, 128 GB disk
VA clusters2+ VAs per cluster; production and sandbox cluster; no DMZ; one VA per host
VA ports443, 53, 123 outbound; 22 inbound internal only
VA reserved ranges10.255.255.241/28 and 172.16.0.0/22 (network tunnel)
Identity profile priorityFirst created = 10, next 20, and so on; lowest number wins
Required identity attributesuid, email, lastname; uid must be unique
Default lifecycle statespre-hire, active, leave of absence, terminated, archived; disabled until enabled; technical name is case-sensitive
Identity statesActive, Inactive (short-term), Inactive (long-term); account delete only with long-term
Lifecycle retriesRetryable failures retried hourly, 3 times
TriggersFIRE_AND_FORGET vs REQUEST_RESPONSE (one subscription only)
SoDViolation = access in both lists; API list limit 50 entitlements
HelpdeskCannot revoke access or set lifecycle states manually
Org AdminDon't combine with other elevated levels
CorrelationConfigure before first aggregation; change = unoptimized aggregation

Suggested Two-Week Plan

Days 1–2: Foundations. Read the Big Picture. Study Domains 8 and 3 (identity profiles, mappings, lifecycle states).

Days 3–4: Data in. Domain 7 (aggregation, correlation, connectors, errors) and Domain 2 (VA requirements, ports).

Days 5–6: Access. Domain 5 (entitlements, access profiles, roles, user levels) and Domain 4 (provisioning and troubleshooting).

Days 7–8: Governance. Domain 6 (requests, approvals, certifications, SoD).

Days 9–10: Platform. Domain 1 (search, PAT and OAuth, workflows, triggers, Config Hub).

Days 11–12: Practice. Quiz yourself with scenario questions: "Where in the flow did it break?" Revisit the tables above.

Days 13–14: Review. Re-read tips, memorize the quick-reference table, rest well before the exam.

Study tips

  • If you have a sandbox or training tenant, click through each setting (identity profile, lifecycle state, source, role, certification). Hands-on practice beats rereading.
  • For scenario questions, name the step (source, aggregation, correlation, identity profile, lifecycle, role, provisioning, governance) and eliminate answers from the wrong step.
  • Watch for words like first, best, least privilege, automatically, preventive and detective. They usually point to one answer.

Things to Double-Check

I could not see the official exam guide, so please verify these against it:

  • The blueprint term "Channels" (Domain 4) is interpreted here, not defined in the docs.
  • Exact workflow trigger and action names can differ slightly by tenant version.
  • Exact timing of when certification revocations are provisioned (this guide says at completion).
  • Any numbers (limits, retention) that SailPoint may have changed recently. The product docs are updated often.

To go deeper on any topic, the documentation sections for Identity Profiles, Lifecycle States, Virtual Appliances, Correlation, Workflows and Separation of Duties are the best use of your time.

No matches. Try a shorter search term.