Free 701-200 practice test: 30 questions with answers

Microservices split an application into small services that are owned and deployed independently. A monolith ships as one unit, waterfall is a sequential project model rather than an architecture, and a shared schema is a data design choice that tends to couple modules.

The twelve-factor methodology keeps configuration separate from code and supplies it through environment variables, so one build can run in any environment. Per-environment binaries, hard-coded values and committed credentials tie configuration to the code, which the methodology avoids.

Build automation tools such as Maven and Gradle compile code, resolve declared dependencies and run tests from one command. An editor only helps write code, version control only records changes, and a container registry only stores and serves images.

A lock file records the exact resolved versions, so builds stay repeatable and a new major release cannot change them unnoticed. Open-ended versions pull in whatever is newest, an untracked global install cannot be reproduced, and deleting tests removes the check rather than protecting the build.

git revert adds a new commit that reverses the earlier change, so the shared history stays intact and teammates can pull normally. Resetting and force-pushing or rebasing a shared branch rewrites history that others have pulled, and git stash drop does not touch commits at all.

Merge creates a merge commit that joins two histories, while rebase rewrites the current branch's commits so they sit on top of the target. The other options swap the two commands or describe behaviour that neither command has.

Continuous integration merges changes frequently and runs automated builds and tests on every push, so integration problems surface early. The other options describe waterfall planning, manual approval boards and long-lived branches, all of which delay integration.

Continuous delivery keeps software ready to release at any time, with a person deciding when it reaches production, while continuous deployment releases every passing change automatically. The other options misplace automated testing or assign scope and roles that do not define the difference.

A non-root user with write access limited to the data directory restricts what an attacker can change after compromising the application. Root group membership, privileged mode and publishing every port each widen the attack surface.

A NetworkPolicy selects pods and defines their allowed ingress and egress traffic, and it is enforced only when the cluster's network plugin supports policies. Certificates belong in Secrets, resource limits are set on containers, and audit events come from the audit policy.

Prometheus normally uses a pull model, scraping HTTP metrics endpoints of its configured targets at a set interval. The other options describe log collection, a push-into-database design or direct memory access, none of which is how Prometheus usually works.

Counters only increase, so the useful signal is their rate of change, which rate() computes over a time range. A raw counter is cumulative, a gauge is the wrong metric type for a counter, and dividing by pod count does not measure the error rate.

Structured entries with consistent fields can be filtered and aggregated, and a central store keeps them after containers are replaced. Container-local files are lost on replacement, while untimestamped text or disabled logging makes searching impossible.

A span is one timed operation, and spans that share a trace ID are grouped into one trace. Context propagated in headers, such as the W3C traceparent header, links spans across services, while traces do not replace metrics and a span is not a log file.

A namespaced Role limited to get and list on pods, bound to the one service account, grants only the access the job needs. The other options grant cluster-wide or administrative access, which goes far beyond what the job requires.

Secrets are only base64-encoded by default, so encryption at rest must be configured on the API server to protect them in etcd. Encoding is not encryption, and the other options describe per-user key encryption, automatic rotation and image storage, none of which is the default behaviour.

Named volumes are managed by the container engine and exist independently of any single container, so the data survives removal of the container. A writable layer is deleted together with its container, and an environment variable or port mapping does not store any data.

An image is a read-only, layered template, and each container is a runnable instance that adds a writable layer on top. Containers share the host kernel rather than booting their own, so the options that reverse the roles or call containers virtual machines are wrong.

Orchestrators such as Kubernetes and Docker Swarm compare actual state with the declared desired state and start replacements when containers or hosts fail. Manual restarts defeat the goal, while bind mounts and multi-stage builds do not restore lost containers.

Layers are created by filesystem-changing instructions and are reused by images that share a base, which saves disk space and transfer time. Existing layers are immutable, and changing an early instruction invalidates the cache for every later instruction.

Docker reuses cached layers until an instruction's inputs change, so copying the dependency manifest before the source keeps the install layer cached across code edits. Removing FROM, moving USER or running steps by hand does not reduce the cost of rebuilding.

A multi-stage build keeps the toolchain in an intermediate stage and copies only the artifacts into the final image. Deleting files in a later layer does not shrink the earlier layers, and docker commit or volumes do not produce a minimal image.

Control groups (cgroups) enforce resource limits such as memory, and Docker exposes them through options on docker run. Namespaces only isolate what a process can see, an environment variable is just data the application may ignore, and a bind mount does not limit usage.

etcd is the consistent key-value store that backs the Kubernetes API and holds the cluster's state and configuration. kube-proxy handles service networking, the kubelet runs pods on one node and the scheduler chooses nodes, so none of them is the state store.

The kube-scheduler watches for pods without a node and assigns each one based on resource requests, constraints and policies. The kubelet only runs pods already assigned to its node, the registry only stores images, and etcd stores state without making placement decisions.

kubectl rollout undo switches a Deployment back to its previous revision by rolling out the earlier ReplicaSet. Scaling to zero stops the application, watching pods only displays them, and a label changes metadata without changing the running image.

kubectl describe prints a pod's status and its events, including scheduling messages such as FailedScheduling. Logs show container output that does not exist yet for a pending pod, and the node list and an exec session do not show the scheduling events.

A Helm chart packages Kubernetes manifests as a versioned unit with templated defaults, and a values file per environment overrides settings such as replica count and hostname. A ConfigMap holds configuration rather than a package, and hand-edited pods or namespace copies give no versioned packaging.

A pod is the smallest unit Kubernetes schedules, and its containers share one network namespace. A Deployment uses ReplicaSets to keep a declared number of replicas running, while containers in one pod are not forced onto separate nodes and Deployments do not store data.

The API server is the only component that talks to etcd directly, and all other components read and write cluster state through its API. The kubelet, the scheduler and kube-proxy do not access etcd themselves, and kube-proxy does not replicate cluster data.