The O365 connector for FIM 2010 comes with a C# rules extension that contains the checks below, most likely the same code is present in both DirSync and AADSync (I mean why break stuff that works).

If any of the checks fail the user being checked won’t be added to the Azure AD Management Agent and will not synch to the cloud.

From \AADConnectorMFSample\AADRulesExtensions on http://www.microsoft.com/en-us/download/details.aspx?id=41165:

// Only provision to Office365 if:
// all the REQUIRED attributes are present,
// even though we flow them out on EAF rules
// we should block here so we do not create
// a new connector if the ingredients are missing
//

trace.TraceWarning(“Object Filtered because AccountEnabled != True”);

trace.TraceWarning(“Object Filtered because msExchHideFromAddressLists == TRUE and a connected object’s RDN contains ‘MSOL'”);

trace.TraceWarning(“Object Filtered because MailNickname or SamAccountName Starts With ‘CAS_'”);

trace.TraceWarning(“Object Filtered because iscriticalSystemObject == TRUE”);

trace.TraceWarning(“Object Filtered because MV Object is NOT a Mail Enabled Group AND SamAccountName is NULL.”);

trace.TraceWarning(“Object Filtered because MailNickname contains ‘{‘ OR SamAccountName contains ‘}'”);

trace.TraceWarning(“Object Filtered because MV.SamAccountName is not present”);

trace.TraceWarning(“Object Filtered because mailNickname starts with ‘SystemMailbox{‘”);

trace.TraceWarning(“Object Filtered because samAccountName equals ‘SUPPORT_388945a0′”);

trace.TraceWarning(“Object Filtered because samAccountName equals ‘MSOL_AD_Sync'”);

trace.TraceWarning(“Object Filtered because displayname is not present on mail enabled group”);

trace.TraceWarning(“Object filtered because its source object is CNF mangled. DN”, mvEntry.ObjectID.ToS tring());

See also http://blogs.technet.com/b/juanand/archive/2011/07/06/office-365-directory-synchronization-tidbits-part-1.aspx