diff --git a/docs/content/en/docs/design/config.md b/docs/content/en/docs/design/config.md
index 15ecc120a8c..834a04083f6 100644
--- a/docs/content/en/docs/design/config.md
+++ b/docs/content/en/docs/design/config.md
@@ -6,11 +6,7 @@ aliases: [/docs/concepts/config]
 ---
 
 You can configure Skaffold with the Skaffold configuration file,
-`skaffold.yaml`. The configuration file should be placed in the root of your
-project directory; when you run the `skaffold` command, Skaffold will try to
-read the configuration file from the current directory.
-
-`skaffold.yaml` consists of several different components:
+`skaffold.yaml`.  The configuration file consists of several different components:
 
 | Component  | Description |
 | ---------- | ------------|
@@ -25,9 +21,64 @@ read the configuration file from the current directory.
 
 You can [learn more]({{< relref "/docs/references/yaml" >}}) about the syntax of `skaffold.yaml`.
 
+Skaffold normally expects to find the configuration file as
+`skaffold.yaml` in the current directory, but the location can be
+overridden with the `--filename` flag.
+
+### File resolution
+
+The Skaffold configuration file often references other files and
+directories.  These files and directories are resolved
+relative to the current directory _and not to the location of
+the Skaffold configuration file_.  There are two important exceptions:
+1. Files referenced from a build artifact definition are resolved relative to the build artifact's _context_ directory.
+   When omitted, the context directory defaults to the current directory.
+2. For [configurations resolved as dependencies](#configuration-dependencies"), paths are always resolved relative to the directory containing the imported configuration file.
+
+For example, consider a project with the following layout:
+```
+.
+├── frontend
+│   └── Dockerfile
+├── helm
+│   └── project
+│       └── dev-values.yaml
+└── skaffold.yaml
+```
+
+The config file might look like:
+```yaml
+apiVersion: skaffold/v2beta11
+kind: Config
+build:
+  artifacts:
+  - image: app
+    context: frontend
+    docker:
+      dockerfile: "Dockerfile"
+deploy:
+  helm:
+    releases:
+    - name: project
+      chartPath: helm/project
+      valuesFiles:
+      - "helm/project/dev-values.yaml"
+      artifactOverrides:
+        image: app
+```
+
+In this example, the `Dockerfile` for building `app`
+is resolved relative to `app`'s context directory,
+whereas the the Helm chart's location and its values-files are
+relative to the current directory in `helm/project`.
+
+We generally recommend placing the configuration file in the root directory of the Skaffold project.
+
 ## Configuration dependencies
 
-In addition to authoring pipelines in a skaffold configuration file, we can also import pipelines from other existing configurations as dependencies. Skaffold manages all imported and defined pipelines in the same session. It also ensures all artifacts in a required configs are built prior to those in current config (provided the artifacts have dependencies defined); and all deploys in required configs are applied prior to those in current config.
+In addition to authoring pipelines in a Skaffold configuration file, we can also import pipelines from other existing configurations as dependencies. Skaffold manages all imported and defined pipelines in the same session. It also ensures all artifacts in a required configs are built prior to those in current config (provided the artifacts have dependencies defined); and all deploys in required configs are applied prior to those in current config.
+
+Note that in imported configurations, files are resolved relative to the location of imported Skaffold configuration file.
 
 ### Local config dependency
 
@@ -107,4 +158,4 @@ requires:
        activatedBy: [profile2, profile3] 
 ```
 
-Here, `profile1` is a profile that needs to exist in both configs `cfg1` and `cfg2`; while `profile2` and `profile3` are profiles defined in the current config `cfg`. If the current config is activated with either `profile2` or `profile3` then the required configs `cfg1` and `cfg2` are imported with `profile1` applied. If the `activatedBy` clause is omitted then that `profile1` always gets applied for the imported configs.
\ No newline at end of file
+Here, `profile1` is a profile that needs to exist in both configs `cfg1` and `cfg2`; while `profile2` and `profile3` are profiles defined in the current config `cfg`. If the current config is activated with either `profile2` or `profile3` then the required configs `cfg1` and `cfg2` are imported with `profile1` applied. If the `activatedBy` clause is omitted then that `profile1` always gets applied for the imported configs.