On an AD source we have two types of users:
Type 1: requires minimum password length of 12 char
Type 2: requires minimum password length of 8 char
Is there a way if we are using password management features to set two different password policies on one source?
Take a look at the documentation found here on adding multiple password policies to a source:
This documentation should help:
Managing Password Policies - SailPoint Identity Services
Basically, you create a policy, then you can add an exception and use filtering to apply another policy to the other set of users identified with the filter.
Hope that helps!
Looks like @gmilunich beat me to the punch 
Either way, hope that gets you on the right track!
Client is also using password interceptor. So we are going to use password sync groups for these users to update the AD accounts on multiple domains.
If you plan to use the Password Sync Groups (which wasn’t mentioned in the original questions) then you’ll have to look at doing it another way, since currently Password Sync Groups do not support multiple password policies, per the documentation.
Given your new requirement, you may have to have 2 sources per AD, one that pulls in Type 1 accounts, and 1 that pills in Type 2 accounts. You could then have a Type 1 Password Sync Group and a Type 2 Password Sync Group. It will be messy, but it is an option given your requirements.
While I cannot come up with any better solution, I believe this is going to cause a lot of issues while configuring JML processes and Access Request/Approval in ISC. One of the major issues would be having 2 Entitlements (in ISC) with same name (and referring to same backend object) due to 2 sources configured for same AD domain. If someone having an account in Source 1 requests for an entitlement from Source 2 (thinking it is from Source 1) ISC will trigger account creation in Source 2 which will result in a duplicate AD account. As @gmilunich mentioned… too messy!! 
Great call out with the entitlements being duplicated. That’s the primary reason I would shy away from this approach. The Account Creation issue could be handled in a Before Provisioning Cloud rule to check if the account already exists (I believe) but again, it is messy.
It may be better to rethink using the Password Sync Groups and try to solve updating all of the account passwords instead.
