OCI supports adding secondary private IP addresses to a compute instance. This is very helpful and one of the use cases is instance failover. If the instance has issues, then the secondary IP address can be reassigned to a standby instance in the same subnet, thus providing high availability. F5’s Big IP VE uses this feature to provide high availability in OCI.
This is all cool and how to do it using console, CLI and API is well documented.

Fig 1
Notice the Unassign checkbox in the above figure. That is used in the instance failover use case described above.
IAM Policy
However, to perform any operations in OCI, the principal needs the requisite permissions which are provided by IAM policies. The policy statements I have come across to achieve the assignment of secondary IP addresses are way too permissive. Many a time they presume that the principal will belong to the default Administrators group. This is not desirable. Instead, policy statements with much narrower permission scope are needed. The policy statements with the minimal set of permissions required for assigning secondary IP addresses to a VNIC are as follows.

Fig 2
Notice the group name AmitTestGroup is prefixed with OracleIdentityCloudService. This is since my tenancy has identity domains and OracleIdentityCloudService is the name of the domain which contains the group AmitTestGroup. If instead, the tenancy did not have any identity domains but just IDCS, then of course there would not be any prefixes.
In the above figure, AmitTestGroup refers to a group of user principals. However, users are not the only type of principals who can initiate configuration updates on OCI services. (Compute) Instance principals can also initiate such updates by making API calls. They too need the same permissions. You can use a dynamic group instead of a user group in the above policy statements to allow instances make API calls for moving secondary IP addresses from one instance to another.