diff --git a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
index 25cd61a710..f0f6f5def9 100644
--- a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
+++ b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
@@ -269,6 +269,24 @@ If etcd is running on a storage volume that supports backup, such as Amazon
 Elastic Block Store, back up etcd data by taking a snapshot of the storage
 volume.
 
+### Snapshot using etcdctl options
+
+We can also take the snapshot using various options given by etcdctl. For example 
+
+```shell
+ETCDCTL_API=3 etcdctl --h 
+``` 
+
+will list various options available from etcdctl. For example, you can take a snapshot by specifying
+the endpoint, certificates etc as shown below:
+
+```shell
+ETCDCTL_API=3 etcdctl --endpoints=[127.0.0.1:2379] \
+  --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
+  snapshot save <backup-file-location>
+```
+where `trusted-ca-file`, `cert-file` and `key-file` can be obtained from the description of the etcd Pod.
+
 ## Scaling up etcd clusters
 
 Scaling up etcd clusters increases availability by trading off performance.
@@ -324,4 +342,3 @@ We also recommend restarting any components (e.g. `kube-scheduler`,
 stale data. Note that in practice, the restore takes a bit of time.  During the
 restoration, critical components will lose leader lock and restart themselves.
 {{< /note >}}
-