200-901 Application Deployment and Security Practice Test 1 — 15 Questions

Question 1

A CI/CD pipeline has a stage that runs security vulnerability scans on dependencies. Which tool is specifically designed to scan Python packages for known vulnerabilities?

Accepted Answer

pip audit. pip audit checks Python packages for vulnerabilities. npm audit is for Node.js, Snyk is a third-party tool, Dependabot automates dependency updates.

Answer

Snyk

Answer

Dependabot

Answer

npm audit

Question 2

In a Docker Compose file with multiple services, one service depends on another to be healthy before starting. Which key should be used to express this dependency and ensure the dependent service is started first?

Accepted Answer

depends_on. depends_on in Docker Compose controls startup order. 'links' is legacy, 'networks' defines networks, 'volumes' mounts volumes.

Answer

volumes

Answer

networks

Answer

links

Question 3

Which TWO Docker network drivers allow a container to communicate with the host's network stack directly?

Accepted Answer

host. Option D (host) is correct because the host driver removes network isolation entirely, placing the container directly in the host's network namespace so it shares the host's interfaces, IP addresses, and ports. Option E (macvlan) is correct because it assigns the container its own MAC and IP address on a parent host interface, making it appear as a distinct physical device on the same Layer 2 network as the host, allowing direct communication with the host's network stack. Option A (bridge) is incorrect because the default bridge driver creates an isolated virtual network with NAT, so containers do not share the host's stack directly. Option B (none) is incorrect because it provides no networking at all, only a loopback interface. Option C (overlay) is incorrect because it is a multi-host driver for Swarm services that encapsulates traffic between Docker daemons, not a direct host-stack connection.

Answer

bridge

Answer

none

Answer

overlay

Question 4

A Kubernetes Deployment has replicas: 3. The team updates the container image to a new version. The rollout gets stuck because the new pod fails readiness probes. Which kubectl command will display the rollout status and help diagnose the issue?

Accepted Answer

kubectl rollout status deployment/my-deployment. The kubectl rollout status command specifically displays the status of a rollout, including the number of updated replicas and any errors. It will show that the rollout is stuck due to the new pod failing readiness probes, providing a clear diagnostic message. This command is designed for monitoring rollout progress and is the most direct way to diagnose a stuck rollout.

Answer

kubectl get pods -l app=my-deployment

Answer

kubectl logs deployment/my-deployment

Answer

kubectl describe deployment my-deployment

Question 5

A developer is deploying a containerized application with Docker Compose. The application requires environment variables for database credentials that should not be hardcoded in the docker-compose.yml file. Which two methods securely provide these credentials? (Choose two.)

Accepted Answer

Use an .env file and add it to .gitignore, then reference it with env_file in the service.. Option C is correct because Docker Compose natively supports an env_file directive that loads variables from a separate .env-style file at runtime, and adding that file to .gitignore keeps the credentials out of version control so they are not hardcoded in docker-compose.yml. Option D is correct because Compose performs variable interpolation on the YAML, so using ${VAR} syntax in the environment block pulls values from the host shell (or an exported environment) at deploy time, again avoiding hardcoded secrets in the file. Options A, B, and E are wrong: a public registry exposes credentials to anyone, hardcoding under environment literally embeds the secrets in docker-compose.yml, and baking credentials into the image during build persists them in image layers where they can be extracted with docker history or by inspecting the filesystem.

Answer

Use a public registry to store the credentials.

Answer

Hardcode the credentials in the docker-compose.yml under environment.

Answer

Store the credentials in the Docker image during build.

Question 6

A Kubernetes cluster has a deployment named 'frontend' that needs to be updated to a new image version. The update should be performed with zero downtime. Which three kubectl commands or approaches can achieve this? (Choose three.)

Accepted Answer

kubectl set image deployment/frontend frontend=myimage:v2. Option A is correct because `kubectl set image deployment/frontend frontend=myimage:v2` triggers a rolling update of the Deployment's pod template, which by default replaces pods gradually while keeping the specified number available, achieving zero downtime. Option C is correct because `kubectl edit deployment frontend` lets you change the container image in the live manifest; saving it causes the Deployment controller to perform the same rolling update strategy. Option E is correct because `kubectl apply -f updated-frontend.yaml` with the new image declaratively updates the Deployment, again invoking the rolling update mechanism for zero downtime. Option B is not correct because deleting and recreating the Deployment destroys all pods first, causing downtime and losing rollout history. Option D is not correct because `kubectl rollout undo` reverts to a previous revision rather than updating to a new image version.

Answer

kubectl delete deployment frontend and then create a new deployment.

Answer

kubectl rollout undo deployment/frontend

Question 7

A developer is writing a CI/CD pipeline using Jenkins Declarative Pipeline. They want to ensure that sensitive credentials (e.g., API keys) are never exposed in console logs. Which two security practices should be implemented? (Choose two.)

Accepted Answer

Store the API key in a Jenkins 'Secret text' credential and use the withCredentials step in the pipeline.. Option A is correct because storing the API key as a Jenkins 'Secret text' credential and accessing it via the withCredentials step is the canonical Declarative Pipeline approach: withCredentials binds the secret to a temporary variable (e.g., API_KEY) and masks its value in console output, so the credential is never written to logs. Option E is correct because the environment directive can reference a Jenkins credential (e.g., environment { API_KEY = credentials('my-api-key-id') }) to inject the secret as an environment variable; Jenkins automatically masks the value in the build log, making it a safe way to expose credentials to pipeline steps. Option B is wrong because hardcoding the key in the Jenkinsfile and echoing it with sh would print the secret directly to the console log, and the Jenkinsfile itself would be stored in source control. Option C is wrong because command-line arguments are visible in process listings and often echoed in build output, so the key could leak. Option D is wrong because printing the API key to the console explicitly exposes it in the log, which is exactly what the question asks to prevent.

Answer

Hardcode the API key in the Jenkinsfile and use the sh step to echo it.

Answer

Pass the API key as a command-line argument to the build script.

Answer

Print the API key to the console for debugging.

Question 8

You are writing a Dockerfile. Which instruction should you use to set the working directory for subsequent RUN, CMD, ENTRYPOINT, COPY, and ADD instructions?

Accepted Answer

WORKDIR /app. The WORKDIR instruction in a Dockerfile sets the working directory for any subsequent RUN, CMD, ENTRYPOINT, COPY, and ADD instructions. This ensures that commands execute from that directory and that COPY/ADD paths are resolved relative to it. Option A is correct because WORKDIR is the only Dockerfile instruction designed specifically for this purpose.

Answer

RUN cd /app

Answer

ENV WORKDIR=/app

Question 9

You are writing a Dockerfile for a Python application. Which instruction should you use to install the dependencies from a requirements.txt file?

Accepted Answer

RUN pip install -r requirements.txt. The RUN instruction executes commands in a new layer on top of the current image and commits the results. Using RUN pip install -r requirements.txt ensures that the Python dependencies are installed during the image build process, making them part of the final image. This is the correct approach because dependencies should be installed at build time, not at container runtime.

Answer

ENTRYPOINT pip install -r requirements.txt

Answer

CMD pip install -r requirements.txt

Question 10

A developer needs to share a Docker image built from a Dockerfile with team members. Which command correctly builds the image and tags it as 'myapp:v1'?

Accepted Answer

docker build --tag myapp:v1 .. Both `docker build --tag myapp:v1 .` and `docker build -t myapp:v1 .` are correct — `--tag` and `-t` are identical flags, and the trailing `.` specifies the build context (current directory containing the Dockerfile). The tag format `name:tag` assigns the repository name `myapp` and version tag `v1`.

Answer

docker build . --name myapp:v1

Question 11

A Kubernetes Deployment manages a set of identical pods. You update the container image to a new version. The rollout gets stuck. Which kubectl command should you use to view the rollout status and determine the cause?

Accepted Answer

kubectl rollout status deployment/my-deployment. The `kubectl rollout status deployment/my-deployment` command is specifically designed to track the progress of a rollout and report its current state, including whether it is stuck or progressing. It provides real-time status updates and can surface underlying issues like image pull errors or resource constraints that cause the rollout to hang, making it the correct tool for diagnosing a stuck rollout.

Answer

kubectl get pods

Answer

kubectl describe deployment my-deployment

Question 12

A developer wants to run a container in the background with port mapping and a named volume. Which command accomplishes this?

Accepted Answer

docker run -d -p 8080:80 -v myvol:/data --name myapp nginx. Options A and C are both correct. Option A uses the `-v` flag to mount a named volume, which is a shorthand for volume mounting. Option C uses the `--mount` flag; when `type=volume` is omitted, it defaults to a volume mount, so `--mount source=myvol,target=/data` is equivalent to `-v myvol:/data`. Both commands create a new container in detached mode (`-d`), map port 8080 on the host to port 80 in the container (`-p 8080:80`), mount the named volume `myvol` to `/data`, and name the container `myapp`. Option B is incorrect because `docker start` only starts an existing container and cannot create a new one or specify port mapping or volumes.

Answer

docker start -d -p 8080:80 -v myvol:/data --name myapp nginx

Question 13

In a Kubernetes cluster, you need to store non-sensitive configuration data (e.g., database hostname) that can be consumed by pods as environment variables. Which resource should you use?

Accepted Answer

ConfigMap. A ConfigMap is the correct Kubernetes resource for storing non-sensitive configuration data like a database hostname. It is designed to decouple configuration artifacts from image content, allowing pods to consume this data as environment variables or mounted files without hardcoding values into container images.

Answer

PersistentVolume

Answer

Secret

Question 14

Which TWO practices help prevent sensitive data exposure in a CI/CD pipeline? (Select two.)

Accepted Answer

Run dependency scanning tools (e.g., Snyk) in the pipeline.. Option A is correct because running dependency scanning tools such as Snyk in the pipeline detects vulnerable or malicious third-party packages before they reach production, reducing the risk that a compromised dependency exfiltrates sensitive data. Option B is correct because injecting secrets via environment variables at runtime keeps credentials out of source code and build artifacts, so they are not exposed in the repository or logs. Option C is wrong because hardcoding credentials in source code directly exposes secrets to anyone with repository access. Option D is wrong because committing .env files, even with dummy values, establishes a risky pattern that can lead to real secrets being committed and leaked. Option E is wrong because disabling HTTPS removes transport encryption, making sensitive data vulnerable to interception rather than protecting it.

Answer

Hardcode credentials in the source code for simplicity.

Answer

Commit .env files to the repository with dummy values.

Answer

Disable HTTPS to avoid certificate management overhead.

Question 15

A Kubernetes cluster runs a microservice that needs to read configuration values from a ConfigMap and sensitive database credentials from a Secret. The pod manifest references both resources. How should the Secret be mounted to avoid exposing sensitive data in logs or environment variables?

Accepted Answer

Using a volume mount with a secret volume. Mounting a Secret as a volume stores the data in the tmpfs (RAM-backed filesystem) of the pod, which is not written to disk and is not exposed via environment variables that could be logged or printed by the application. This approach prevents accidental leakage of sensitive data through log outputs or environment variable dumps, as the application must explicitly read the file from the mount point.

Answer

Hardcoding the credentials in the ConfigMap

Answer

Using a sidecar container to fetch secrets via API

Answer

Using envFrom with secretRef