## TL;DR
Fix the underlying target error shown in the provisioning logs, then restart provisioning to clear the quarantine. Quarantine is a protective pause, not the root problem.

## Error
```text
Provisioning quarantine: the target system returned repeated errors
```

## Steps
1. Open the Entra provisioning logs for the app and read the error that triggered the quarantine. Expected: the concrete target error identified.
2. Fix that error on the target side (credentials, schema, throttling, or data issue). Expected: the root cause resolved.
3. In the Entra portal, restart provisioning for the application to clear the quarantine state. Expected: the status leaves quarantine.
4. Monitor the next sync cycles to confirm users provision cleanly. Expected: successful syncs with no re-quarantine.

## When to use
- Entra shows the provisioning job in quarantine
- Provisioning worked before and stopped after target errors
- The logs show repeated target failures

## When not to use
- Provisioning never worked (a setup problem, not quarantine)
- The job is paused manually (resume it instead)
- The target is decommissioned (remove the provisioning config)

## Tool compatibility
Microsoft Entra ID provisioning service. Quarantine behavior is the same for gallery and custom apps.

### Variant phrasings
### quarantine recurs after clearing
The root cause was not actually fixed. Read the newest log entries, not the old ones.

### quarantine after a target upgrade
Re-validate the connection and the attribute mappings against the upgraded target.

## Why it happens
Entra quarantines a provisioning job after repeated target errors to avoid hammering a broken endpoint. Clearing the flag without fixing the error just re-triggers it.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lhMu8ff9c7ln1rr2dGJo1A