diff --git a/2-StudentDB/2-StudentDB/a2_questions.md b/2-StudentDB/2-StudentDB/a2_questions.md
index 20fc9a127c8a9f61f823bd2b6ccfc791b677f766..a8553499e8745fb944d854e95c3abb7edbef329b 100644
--- a/2-StudentDB/2-StudentDB/a2_questions.md
+++ b/2-StudentDB/2-StudentDB/a2_questions.md
@@ -7,10 +7,10 @@ Please answer the following questions and submit in your repo for the second ass
 
     > **Answer**: Yes, externalizing `get_student()` improves the design because:
     > 
-    > 1. It avoids duplicating file access code across multiple operations (finding, deleting, adding students)
-    > 2. It separates the low-level file access details from higher-level database operations
-    > 3. Changes to how students are read only need to be made in one place
-    > 4. The isolated function is easier to test
+    > - It avoids duplicating file access code across multiple operations (finding, deleting, adding students)
+    > - It separates the low-level file access details from higher-level database operations
+    > - Changes to how students are read only need to be made in one place
+    > - The isolated function is easier to test
 
 2. Another interesting aspect of the `get_student(...)` function is how its function prototype requires the caller to provide the storage for the `student_t` structure:
 
@@ -44,7 +44,7 @@ Please answer the following questions and submit in your repo for the second ass
     ```
     Can you think of any reason why the above implementation would be a **very bad idea** using the C programming language?  Specifically, address why the above code introduces a subtle bug that could be hard to identify at runtime? 
 
-    > **Answer**: This implementation is dangerous because it returns a pointer to a local variable (`student`) that is destroyed when the function returns. Using this pointer would cause undefined behavior since it points to invalid memory. This is a common source of bugs in C programs since the memory corruption may not be immediately apparent.
+    > **Answer**: This implementation is dangerous because it returns a pointer to a local variable `student` that is destroyed when the function returns. Using this pointer would cause undefined behavior since it points to invalid memory.
 
 3. Another way the `get_student(...)` function could be implemented is as follows:
 
@@ -79,10 +79,10 @@ Please answer the following questions and submit in your repo for the second ass
     
     > **Answer**: While this implementation would work, it has important drawbacks:
     >
-    > 1. It requires callers to remember to free the memory, risking memory leaks
-    > 2. NULL return is ambiguous - could mean "not found" or "allocation failed"
-    > 3. Unnecessarily allocates memory when passing existing memory would work
-    > 4. Different callers might manage the memory inconsistently
+    > - It requires callers to remember to free the memory, risking memory leaks
+    > - NULL return is ambiguous - could mean "not found" or "allocation failed"
+    > - Unnecessarily allocates memory when passing existing memory would work
+    > - Different callers might manage the memory inconsistently
 
 4. Lets take a look at how storage is managed for our simple database. Recall that all student records are stored on disk using the layout of the `student_t` structure (which has a size of 64 bytes).  Lets start with a fresh database by deleting the `student.db` file using the command `rm ./student.db`.  Now that we have an empty database lets add a few students and see what is happening under the covers.  Consider the following sequence of commands: