diff --git a/docs/README.md b/docs/README.md
index 79f40ca38..0289c1da5 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -6,6 +6,7 @@
 * [Build from scratch][0]
 * [Cloud provider specifics][9]
 * [Debugging restores][4]
+* [FAQ][10]
 
 ## Reference
 * [CLI reference][2]
@@ -27,3 +28,4 @@
 [7]: use-cases.md#disaster-recovery
 [8]: use-cases.md#cluster-migration
 [9]: cloud-provider-specifics.md
+[10]: faq.md
diff --git a/docs/faq.md b/docs/faq.md
new file mode 100644
index 000000000..cb4d7f782
--- /dev/null
+++ b/docs/faq.md
@@ -0,0 +1,20 @@
+# FAQ
+
+## When is it appropriate to use Ark instead of etcd's built in backup/restore?
+
+If you only want to backup/restore a single etcd cluster, you're probably better off using etcd's
+built in backup and restore tooling.
+
+Ark is useful for:
+
+* backing up etcd resources and persistent volume state
+* cluster migrations
+* backing up a subset of your Kubernetes resources
+* backing up Kubernetes resources that are stored across multiple etcd clusters (for example if you
+  run a custom apiserver)
+
+## Will Ark restore my Kubernetes resources exactly the way they were before?
+
+Yes, with some exceptions. For example, when Ark restores pods it deletes the `nodeName` from the
+pod so that they can be scheduled onto a new node. You can see some more examples of the differences
+in [pod_restorer.go](https://github.com/heptio/ark/blob/master/pkg/restore/restorers/pod_restorer.go)