An alternate approach came to mind when doing this exercise: You could update the queries we've used to perform the authentication rather than doing them in the controller logic afterward, although by taking this approach, it is less clear that the side effect intended is authentication. Still, it could be left in as a way to ensure that the database query will only work if the current user matches the note's user_id.

$query = "select * from notes where id = :id AND user_id = :user_id";
$note = $db->query($query, [
	'id' => $id,
	'user_id' => $currentUserId
])->findOrFail();

OR maybe it is more useful for delete (you don't even need to select it first if you do the delete query in this way):

$query = "delete from notes where id = :id AND user_id = :user_id";
$db->query($query, [
	'id' => $id,
	'user_id' => $currentUserId
]);

I realize that this is sort-of a moot point with all the authentication helpers in frameworks like Laravel, and that doing a select to retrieve the note first and then authorize in the controller logic is very clear to understand. Including the authorization logic in the controller also allows us to handle it more explicitly and give feedback to the user in future refactors (whereas relying on it only being in the database query makes it hard to know what went wrong/what the reason for the operation failing would be). This idea just came to mind as I was writing this myself before seeing your solution - why not include the user_id in each query just to be safe? Other people may have that idea, too, but it seems like the main reason to keep the authorize logic outside of the DB query is to know if the issue is Record Not Found or Unauthorized, and then be able to respond 404 or 403 to the user. Great lesson and thought provoking!

Handle Multiple Request Methods From a Controller Action?