Jcdvzbm

        if (k > 0 && head != null) {
            ...
            return RotatedList;

        }

        return head;

would be clearer (and more consistent with the other special case) as

        if (k <= 0 || head == null) {
            return head;
        }

        ...
        return RotatedList;

(although really if k < 0 I think it should throw new ArgumentOutOfRangeException(nameof(k))).

            ListNode tail = head,
            RotatedList = null,
            kthnode = head,
            kthPrevNode = head;

Most of these don't need to be declared so early. Declaring variables as late as possible (and, more generally, in the narrowest scope possible) helps to reduce cognitive load when maintaining the code.

            int listLength = 0;
            while (tail != null) {
                listLength += 1;
                tail = tail.next;
            }

This would be worth factoring out as a separate method Length(ListNode head).

            k = k % listLength;
            if (k == 0 || listLength == 0) {
                return head;
            }

This is sort-of buggy. If listLength == 0 then k % listLength will throw an ArithmeticException. However, you can never reach here in that case, because listLength == 0 is equivalent to head == null, and that was already handled in the first special case. To remove confusion, delete || listLength == 0. If you want to validate that condition, insert System.Diagnostics.Debug.Assert(listLength > 0); before the % line.

            for (int i = 0; i < listLength - k; i++) {

                kthPrevNode = kthnode;

                kthnode = kthnode.next;

            }

It's not actually necessary to track two nodes here. The invariant is that kthPrevNode.next == kthnode, so it suffices to track kthPrevNode.

Also, the blank lines seem excessive to me.

            RotatedList = kthnode;

It's conventional in C# that local variable names start with a lower case letter, so to avoid confusion I would rename RotatedList to rotatedList (or perhaps rotatedHead).

There are only two things where I can see that the efficiency can be improved: one is eliminating kthnode in the loop, as commented above; the other would be to hang on to the last node when finding the length, so that you don't need to find it a second time in the last few lines. (That would imply changing the factored out method to return an (int, ListNode) tuple).

As for time complexity, it's already optimal: linear time. Good job!

• Using an uppercase name for a variable is a bad practise; should be rotatedList or preferably res for result or something similar.

• Separate your instantiations with semicolons:

            ListNode tail = head;
            ListNode rotatedList = null;
            ListNode kthnode = head;
            ListNode kthPrevNode = head;

• Your naming of head and tail is confusing. Consider renaming them.

• Use if (k <= 0 || head == null) return ...; rather than having a huge if embracing all the method.

• Use preincrements listLength += 1; \\$\\to\\$ ++listLength;. You can also name that variable just length (it's obvious we're talking about lists).

• Your variable kthPrevNode seems useless. You should remove it.

Performance optimization

int listLength = 0;
while (tail != null) {
    listLength += 1;
    tail = tail.next;
}

Since head != null we can start listLength at 1 and keep our tail by checking tail.next != null rather than tail != null.

int listLength = 1;
while (tail.next != null) {
    listLength += 1;
    tail = tail.next;
}

Now we no longer have to search for kthnode because it's tail.

// no longer required
while (kthnode.next != null) {
    kthnode = kthnode.next;
}

Misc

• Since the challenge uses mathematical style variable names, such as k, I suggest to rename listLength to n.
• The challenge states k can be asserted non-negative, so I presume k > 0. On the other hand, your method is public, so any input could be provided. The challenge does not specify how to handle 'wrong' input. Several ways to perform the argument checks have already been suggested in other answers. One other possibility is to use a sand-box. Left-rotations (k < 0) are inversional equivalents of right-rotations. So the following relaxation on k deals with any right-rotation, even the ones specified as left-rotation: k = (k % n + n) % n;.