Q:

how to make my code clean, code shows below

I'm playing with aws dynamodb, and want to update a specific payloadField, I want to have two test cases, one is specify the payloadField with a string(e.g, "myPayload"), since payloadField is optional, another one I don't want specify this parameter, in this case, the name of the DynamoDB column is default to "payload". 
Below is my current code, this method used to setup my ddb with specify payloadField, I don't want to have another method like
 private String setUpRule( String topic, String hashKeyValue, String rangeKeyValue, String operation) {**}

which used for another test case, how can I put them into one method that can be used for my two cases? 
 private String setUpRule(String payloadField, String topic, String hashKeyValue, String rangeKeyValue, String operation) {

        // create golden eye rule
        Action action = new Action();
        DynamoDBAction dynamoDBAction = new DynamoDBAction();
        dynamoDBAction.setTableName(dynamoHelper.getStagedRegionalizedTableName());
        dynamoDBAction.setRoleArn(testRoleArn);
        dynamoDBAction.setOperation(operation);
        dynamoDBAction.setHashKeyField(dynamoHelper.getActionHashKeyField());
        dynamoDBAction.setHashKeyValue(hashKeyValue);
        dynamoDBAction.setRangeKeyField(dynamoHelper.getActionRangeKeyField());
        dynamoDBAction.setRangeKeyValue(rangeKeyValue);
        dynamoDBAction.setPayloadField(payloadField);
        action.setDynamoDB(dynamoDBAction);

      ***
    }

A:

A method with more than 2-3 parameters is usually a sign of bad design (a method with too many responsibilities for example). 
A method with 3+ parameters all of the same (primitive) type is very fragile and confusing to use. 
There is a whole set of Creational Design Patterns (Builder, Prototype) aiming to address this problem, but usually splitting the method into smaller and focused methods or introducing of a new data class composing all required information as a single parameter is enough. 
Back to the question, if method signature should be preserved, a workaround (ugly and not recommended) is to allow payloadField to be passed as null and override it in the body of the method:
 private String setUpRule(String payloadField, String topic, String hashKeyValue, String rangeKeyValue, String operation) {

   payloadField = Objects.requireNonNullElse(payloadField, "payload");

   ***
 }

A more practical solution would be to use the existing 4-parameter setUpRule method to call the 5-parameter one:
private String setUpRule( String topic, String hashKeyValue, String rangeKeyValue, String operation) {
    return setUpRule("payload", topic, hashKeyValue, rangeKeyValue, operation);
}

However I'm more concerned on the following things and would make sure there're very good reasons for those the be set like that:

Why there are multiple overloads of the setUpRule method?  How is the code repetition avoided? 
Why a private method named setUpRule has a String return type?  Either the name or the return type is wrong as this combination doesn't communicate well this method's purpose.