Simple Capital City Quiz in Python3
The classes' hierarchy and their names don't make much sense to me. Ideally, a class should represent one well-defined entity. What kind of entity is StartQuiz? The name is confusing and there's no documentation to clarify it. I'd recommend naming it properly (something like QuestionsLoader) and appropriate doc comments. 

It also mixes up reading the input and choosing random questions. These are different things so they belong to different methods (and possibly even different classes). 

The DisplayAnswer is also a very strange class name (it's something like  OutputFormatter, isn't it?). I ask the same question again: "What kind of entities do its instance represent?" and I can't really answer it. The inheritance doesn't make any sense here. Inheritance represent "is-a" relation. Is a DisplayAnswer a StartQuiz? With such names, the question sounds very weird, but even with proper renaming the answer is clearly no (I don't see any rationale behind an affirmative answer here). 

The same applies to the DisplayQuestion class.

There's one more thing: there's pretty much no point in having a class that has one method that prints something to the output and doesn't encapsulate any state. You're even using it as a function: DisplayAnswer(startQuiz.set_up()[0], startQuiz.set_up()[1]).show_answer(). It could be just a function show_answer, couldn't it? The situation with the DisplayQuestion is the same here.

Even if you want to keep them all as classes, I'd strongly recommend taking a step back and redesigning your system. Having classes for the sake of having classes makes no sense. There should be some kind of "physical" (or "real world") meaning to them. You can start with the following questions:


What kind of entities are there in this problem? Typically, an entity can and should be described with a noun like loader, formatter and so on. 
Once you know what these entities are, you can think of the classes to implement them (but again, the "physical" meaning comes first. If something is just one simple stateless action, I'd rather make it a function). 
This part also includes designing the relations between the classes. Inheritance means "is-a". Before building a hierarchy, ask yourself: "Is X really Y?").


There're a lot of other issues with this code (hardcoded file names, improper default arguments use, lack of documentation and tests and so on), but I think that fixing the high-level design is the first thing to do right now. It's impossible to write good code without modeling the problem properly, so that comes first.