This will sound flippant, but that's not what Dynamo is for. If you want to do freeform relational queries like that then put it in a relational database.
Dynamo is primarily designed for high volume storage/querying on well understood data sets with a few query patterns. If you want to be able to query information on employees based on their name and city you'll need to build another index keyed on name and city (in practice Dynamo makes that reasonably simple by adding a secondary index).
Amazon has a perfect use case for this. You click on a product in the search results, that url contains a UUID, that UUID is used to search Dynamo and returns an object that has all the information on the product, from that you build the page.
If what you are trying to do looks more like "Give me all the customers that live in Cuba and have spent more than $10 and have green eyes", Dynamo isn't for you. You can query that way but after you put all the work in to get it up and running, you'd probably be better off with Postgres.
If that's one of 12 or less query patterns you need, I can write you a simple dynamo table for it.
Dynamo's limitation is that it can only support n different query patterns, and you have to hand craft an index for each one(well, sometimes you can get multiple on one index)
Alternatively, practice single table design: structure your table keys in such a way that they can represent all (or at least most) of the queries you need to run.
This is often easier said than done, but it can be far less expensive and more performant than adding an index for each search.
Dynamo is primarily designed for high volume storage/querying on well understood data sets with a few query patterns. If you want to be able to query information on employees based on their name and city you'll need to build another index keyed on name and city (in practice Dynamo makes that reasonably simple by adding a secondary index).