This isn't strictly correct, but the way you can view partition key's is they define a 'group', and row keys identify specific records within that group.
It's important to understand how Azure Storage works, in order to model your data most efficiently. You're correct that partition's are stored on the same node, and the only indexes you have (for fast lookups) are partition keys and row keys.
In your student record example, what's this record being used for, or rather, how are records "grouped" together? If this is a class attendance list, maybe your PartitionKey is the course id, and RowKey's are individual student id's (PartitionKey = CourseId, RowKey = StudentId). In this case, you can fetch an entire partition and get the full course roster, or you can look up an individual student with PartitionKey + RowKey.
Another way might be to give each student their own partition (PartitionKey = StudentId), and then row key's are specific dates (RowKey = Date). With this model, you can quickly fetch a student's entire attendance history by querying just the PartitionKey, or if you want to see whether they were in attendance on a specific day, query PartitionKey + RowKey (StudentId + Date).
There's multiple way's to model your data. It just depends on how you're using these specific records for what's optimal.