tl;dr: Just say no.
This question is difficult on many levels. I seems to me to be a land mine of misconceptions and has the possibility to lead to poor teaching practice.
First the difficulties
Only concepts can be abstract. Abstraction is about ideas. Animal is a concept. Mammal is a concept. Animal is more abstract than Mammal since it contains the idea of Mammal, but isn't restricted to it. The kitty sitting on my hearth is concrete, not less abstract than Mammal. The kitty isn't a concept it is a thing.
Given some ot the examples, there is a misconception about what is abstract and what is concrete. Physical things are not abstract. One can't be more abstract than another. Even things that aren't physical, but which can be manipulated, are concrete, not abstract. A LinkedList (Java) isn't abstract. It is concrete. List, on the other hand (an interface) is abstract.
In computing there are many, many different kinds of abstraction. Even the concept of a while loop is an abstraction. In OOP languages classes implement abstractions. Interfaces (even if the language doesn't have that explicit feature) are abstractions. So, Python has interfaces, though it has no language feature with that name. If two classes have the same interface they are realizations of the abstraction, but neither is more or less abstract than the other. If one interface contains another interface then it is more abstract.But we also have data abstraction. Lists and Maps define an interface (an abstraction). They can be implemented/realized many ways. Each realization is concrete, not less abstract.
The web site cited seems to be trying to test everything with Multiple Choice Questions (MCQ). I question both the possibility of that and the wisdom of it. Some thing are complex MCQ are simple. Trying to push the assessment of complex things through such a small funnel seems misplaced to me - even foolish. I'm pretty sure that MCQ also advantage certain students and disadvantage others. They are fine for rote memory and facts, but pretty poor for deep understanding. I have nothing against their use unless it is overdone. MCQ are also difficult to validate. The wisdom of groups isn't enough. It takes statistical measurement and cross validation to do a good job of it.
The Font Construction example given in the question also seem to be testing specific vocabulary. This example threw me completely. I think I could eliminate one answer, but also think I could justify each of the others if given the chance. If it is specific vocabulary it is just rote memory and hoping that the student "remembered" to remember the right thing.
Often, getting a MCQ wrong and then later learning the correct answer can sometimes leave students simply puzzled and frustrated. This results in a destructive game that I'd rather not play.
MCQ try to put a lot of thinking into the questions so that no one needs to put any thinking into the answers after the student finishes. This may scale well, but is a sub-optimal form of education. After all, it is the students thoughts that we want to get a handle on in assessment.
I don't believe that a single, or even a small number of MCQ could capture the student's understanding of abstraction or any similarly deep concept. I think that if you had quite a lot of questions (say 20-50 of them) you might be able to get a handle on it, but it would take very careful cross evaluation of the answers given to be able to say with any confidence. Getting a single question wrong likely tells you almost nothing. And that, of course, makes MCQ less valuable for its main use - quick and easy evaluation.
I could, on the other hand create a bunch of questions that start to get at the student's understanding. The ones I'd like to use are short response questions, but some can be simple choices.
Assuming that the student have a common language background, something like "Is java.util.List abstract or concrete?" "Is java.util.Collection more or less abstract than java.util.Map". One choice for the answers needs to be neither of course.
You can show code fragments and ask whether they implement an abstraction properly or not. But a follow up "why or why not" gives you better information. And some of those questions would necessarily be a bit long to be meaningful and thus take some time for the student to evaluate.
"How can functions be considered abstractions?" Well, that was poorly stated, since a single function is concrete, not abstract, so you need to be careful: "How can the idea of a function be considered an abstraction?" is better. You could probably give a few suggestions for answers to this to turn it in to a MCQ, but it would be hard to come up with four, of which three were viable and yet not correct.
However, I've only hit the surface here and only explored a very small part of the abstraction space in computing.
Caveat: I never had to teach or evaluate a hundred or more students at a go. My classes were always small enough that I could use better evaluation techniques than MCQ, though would be likely to use a few in a larger assessment that allowed the students more creativity. If you do have to evaluate 800 students I hope you have help. If you don't something is deeply wrong. I note that Harvard CS 50 is run by a team of about 80 people, with quite a number of roles. I hope that each student has some individual person responsible for them. It isn't the professor.
My initial "just say no" is to the idea that you can completely evaluate a student with MCQ, not that they can't be useful, dangerous drug though they are. And note that I have the highest respect for Simon Peyton-Jones.