return size() > 0;

Typo, should be (less than or) equal zero.

    for(int i = 0; i < length; i++) {
      elements[i] = null;
    }
    length = 0;

It might be interesting to actually throw the array away and get a clean one in place, for example if this list was previously filled with 100 million entries.

  public boolean add(T element) {
    ensureCapacity(length + 1);
    elements[length++] = element;
    return true;
  }

Given that this can never return false, it might be interesting to return a more meaningful value instead, for example the current instance. That would allow a fluent use when adding multiple values:

dynamicArray
        .add(someObject)
        .add(anotherObject)
        .add(yetAnotherObject);

Your remove accepts null, indexOf does not. Both should accept null, then you can also use indexOf in remove.

  public boolean remove(T element) {
    int index = indexOf(element);
    
    if (index >= 0) {
        removeElement(index);
        
        return true;
    } else {
        return false;
    }
  }

  private void ensureCapacity(int minSize) {
    if(minSize >= capacity) {
      capacity *= 2;
      elements = Arrays.copyOf(elements, capacity);
    }
  }

Depending on the use-case, this might be overkill. Maybe a little bit more flatter, conservative curve might be appropriate.

  private void validateIndexValue(int index) {
    if(index >= length || index < 0) {
      throw new IllegalArgumentException("Bad index value passed : " + index);
    }
  }

Split it into two exception, one for negative values and one for too large values, to make it easier to debug.

You stuck to the conventions already established in the Java world, that's great, so is your naming of things for the most part. I'd rename validateIndexValue to verifyIndex or assertIndex, though, "assert" might yield the wrong message.

As far as I can see, you can infer capacity from the array size.

Overall, looks quite well. Javadoc is missing, you should write one, it's a good exercise and will make you recheck your implementation.

Let's talk API design.

public class DynamicArray<T> implements Iterable<T> {
  private Object[] elements;
  private int length = 0;
  private int capacity = 0;

  public DynamicArray();
  public DynamicArray(int capacity);
  public int size();
  public boolean isEmpty();
  public T get(int index);
  public void set(int index, T element);
  public void clear();
  public boolean add(T element);
  public T removeAt(int index);
  public boolean remove(T element);
  public int indexOf(T element);
  public boolean contains(T element);
  public java.util.Iterator<T> iterator();
  
  private void removeElement(int index);
  private void ensureCapacity(int minSize);
  private void validateIndexValue(int index);
}

Your class is only extensible as far as the public methods go. If I wanted to extend this class and implement a swap method, I will have a hard time doing that. Implementing a different size strategy will basically mean rewriting methods. Now, how could we improve that situation? The easiest is to make the internal properties protected, it's not exactly a neat or fancy solution, but if somebody wants to implement additional methods, they will have all the necessary access.

public class DynamicArray<T> implements Iterable<T> {
  protected Object[] elements;
  protected int length = 0;
  protected int capacity = 0;

  // public SNIP
  
  protected void removeElement(int index);
  protected void ensureCapacity(int minSize);
  protected void validateIndexValue(int index);
}

That gives every extending class the same access as you had, meaning that implementing a swap method or different strategy will be easy to do. But many people will now start ranting about how that is bad design (I disagree on that matter, but let's leave it at that). So we arrive at the question: Can we give an extending class enough access to implement additional functionality, but also protect base functionality? For example, now elements could be null after any call.

We can, we can guard our elements array behind some functions that ensure its well being:

public class DynamicArray<T> implements Iterable<T> {
  private Object[] elements;
  private int length = 0;
  
  protected final Object[] getElements[] {
      return elements;
  }
  
  protected final int getLength() {
      return length;
  }
  
  protected final setElements(Object[] elements, int length) {
      requireNotNull(elements);
      requireZeroOrPositive(length);
      requireLessThan(length, elements.length);
      
      this.elements = elements;
      this.length = length;
  }
  
  protected final setLength(int length) {
      requireZeroOrPositive(length);
      requireLessThan(length, elements.length);
      
      this.length = length;
  }
  
  // SNIP methods as above
}

Neatish, I'd say. This allows us to make fair assumptions about the internal state. It also gives the extending class any freedom to access and modify the array, without the possibility to nulling the reference. Note that modifying the array directly is still possible, and I'd argue that that should stay that way, because the extending class must be able to modify it. Forcing the extending class to retrieve a copy of the array, modify that copy and set it back will do nothing but waste memory and processing power.

With that in place, a swapping method in an extending class can look like this:

public void swap(int firstIndex, int secondIndex) {
    validateIndexValue(firstIndex);
    validateIndexValue(secondIndex);
    
    Object[] elements = getElements();
    
    T firstElement = elements[firstIndex];
    T secondElement = elements[secondIndex];
    
    elements[firstIndex] = secondElement;
    elements[secondIndex] = firstElement;
}

Which is as simple as it can get.

Of course, the internal state can still be "corrupted" to a certain part, by setting a "wrong" length value, but I'd argue that that is the problem of the extending class. After all, the extending class could also override add to perform a division with zero. We can't and should not guard against anything, otherwise you'll have a too restrictive API/class design which will make it impossible to extend your classes. In the real world, that means to either throw out your class, or copy and modify the code of the class.