AWS 1. Creating an ec2 instance 2. Writing a lambda function 3. s3
This is very non-exhaustive but would cover the very basic. Good luck!
For Nosql try writing something simple with redis, look at mongodb etc
Therefore, if you feel weak during the interview when asked about one of these technologies, you should defer to speaking about your experience interacting with it as an iOS dev. For example, speak about a backend API you had to interact with, and how the queries it allowed you to make impacted your iOS architecture. Talk about JSON, relations, indexes, etc. Challenges you faced, problems you discovered, lessons you learned. Make it relevant to both iOS and whatever technology the interviewer is asking about.
It’s never a bad idea to tell a story.
0. Understand the use-case: What's the point of using docker for dev, production, etc. Read about the 12-factor app by Heroku.
1. Make sure you understand why ppl use init systems vs launching multiple processes inside a container
2. Why ppl use a container vs a VM
3. Can you run windows on a docker daemon running on linux host? If yet how? If not why? Can you run a linux container on a mac host? If not why? If "yes" how?
4. Make sure you understand the different network drivers (host, bridge, overlay, etc.) and what they do
3. Know what are orchestration tools (swarm, kubernetes, mesos, rancher, etc). Why do we use them, what problems do they solve? I'm guessing that this is out of the scope of the interview, if it's not, make sure you understand how to solve: Service discovery (consul, etcd, build-in), Traffic routing (mesh network, port mapping, etc.) and Persistency (EBS volumes via rexray plugin or cloudstor, other tech.). Try to design a fully automated deployment cycle, basic steps should be: deploy, test on push (Jenkins/Drone/other CI tools), run on staging (ab/qa testing?), then push into production (git branching models?!).
Regarding AWS:
1. AWS is a shit-show in the sense that there is too much to know, from an admin perspective. Companies use just a subset, but which one?! Usually people will about the following: EC2 instances (basic types, like T, M, I, etc.). Storage options for throughput (EBS volumes types: io1, gp2, st1, sc1). When to use which one.
2. S3, storage options and types. I will serve you better if you understand what AZ and Regions are and how they are spread geographically. If you have time to dive into "Object Lifecycle Management" which involves Glacier, would be nice. Also make sure you understand the "s3 read-after-write consistency" model, which is different for writes and deletes.
3. Take a look at RDS offerings vs DynamoDB (See NoSQL bellow).
4. Other services to look at: ElasticCache, Route53, CloudFormation, Lambda, IAM.
Regarding NoSQL:
1. What RDS (SQL databases) / NoSQL (dynamodb) does AWS offer and which one offers what. It's a bit too much for an entry level question but Aurora vs MySQL AWS Offering could be a tricky question, very AWS specific.
2. I've wrote a high-level MySQL vs NoSQL overview here: https://www.convalesco.org/articles/2016/11/10/a-quick-overv... - you can start from there and deep-dive into NoSQL databases. A good way to approach databases is in terms of the CAP theorem and what it offers[1]. It's a triangle, you can pick "2" or choose a spot anywhere in between. The choice usually depends on a variety of facts (e.g. do you value more Consistency, Availability or Partition Tolerance?). Each DB (e.g. MongoDB vs DynamoDB) have specific characteristics. I'd say that it's best to study at least 2 of them and then try to understand what each offering gives and why. Also makes sure you take a look at Redis. I'd argue the the other most famous and widely used NoSQL is ElasticSearch but ppl doesn't think (for some reason) about ES when talking about NoSQL... I've noticed that they usually when they talk about NoSQL they usually talk about MongoDB, DynamoDB, Cassandra and Couchbase (the order is random although Mongo is probably the most widely used). From an admin POV you should know how replication works, what happens if the master or slave goes down, how master election/quorum is achieved, etc. It's different and tricky for each DB... I'm not sure if it's worth diving into details, maybe watch a few videos on youtube and take notes. The important thing to know is that in a "master/slave" setup usually you scale-out through master -> slave replication, by scaling out reads not writes. You need master-master replication, but then you introduce another set of problems (consistency vs availability, etc.)
That's not an exhaustive list of course, but you get the point.
Good luck & stay strong!