Application Deployment and Security practice questions

pip audit

pip audit scans Python packages for vulnerabilities.

depends_on

depends_on declares startup and shutdown ordering between services in Docker Compose, ensuring the dependency starts before the dependent service. Health-based gating requires the condition form (service_healthy), but depends_on is the key expressing the dependency itself.

host

The host driver removes network isolation entirely, placing the container directly in the host's network namespace so it shares the host stack and interfaces. This is the direct, unmediated host-stack access the question requires, unlike bridge or overlay.

macvlan

macvlan assigns the container its own MAC address on the parent interface, making it appear as a distinct device on the physical network. Traffic reaches the host's underlying stack and LAN directly, satisfying direct host-stack communication without NAT.

kubectl rollout status deployment/my-deployment

kubectl rollout status reports progress of the Deployment rollout and surfaces the stalled state caused by failing readiness probes, letting the team diagnose why new pods never become ready. It directly addresses the stem's stuck rollout.

Use an .env file and add it to .gitignore, then reference it with env_file in the service.

An .env file referenced through env_file injects variables at runtime, and adding it to .gitignore keeps credentials out of version control. This satisfies the no-hardcoding constraint, since values never appear in docker-compose.yml or the committed repository.

Define the variables in the environment block of docker-compose.yml, with values from shell variables using ${VAR} syntax.

Referencing shell variables with ${VAR} syntax in the environment block passes credentials from the host shell at runtime, so no literal secrets are written into docker-compose.yml. This satisfies the no-hardcoding constraint provided the variables are exported rather than committed.

kubectl set image deployment/frontend frontend=myimage:v2

Directly updates the image, triggers rolling update.

kubectl edit deployment frontend and change the image.

Triggers a rolling update.

kubectl apply -f updated-frontend.yaml with the new image.

Applies the new desired state, triggering rolling update.

Store the API key in a Jenkins 'Secret text' credential and use the withCredentials step in the pipeline.

Storing the key as a Jenkins 'Secret text' credential and wrapping usage in withCredentials injects it as a masked binding, so Jenkins automatically redacts the value from console output. This directly satisfies the requirement that API keys never appear in build logs.

Set the API key as an environment variable using the environment directive, referencing a Jenkins credential.

Using credentials in environment directive masks the value.

WORKDIR /app

WORKDIR sets the working directory for all subsequent Dockerfile instructions.

RUN pip install -r requirements.txt

RUN executes pip install -r requirements.txt during the image build, installing the declared dependencies into the image layer. COPY only transfers the file without installing anything, so RUN is the instruction that satisfies the dependency installation requirement.

docker build --tag myapp:v1 .

The --tag flag assigns the repository name and version (myapp:v1) to the image during the build, and the trailing dot supplies the build context containing the Dockerfile. This single command both builds and names the image, ready for pushing to a registry for teammates.

docker build -t myapp:v1 .

The -t flag assigns the repository name and tag myapp:v1 to the built image, and the trailing dot sets the build context to the current directory containing the Dockerfile. This produces a correctly named, shareable image that teammates can pull or run.

kubectl rollout status deployment/my-deployment

kubectl rollout status reports the live progress of the Deployment rollout, showing whether new pods become ready or stall, and surfaces the blocking condition. This directly satisfies the need to view rollout status and determine why the update is stuck.

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

The -d flag detaches the container to run in the background, -p 8080:80 maps host port 8080 to container port 80, and -v myvol:/data mounts the named volume. Together these satisfy every stated requirement in a single command.

docker run -d -p 8080:80 --mount source=myvol,target=/data --name myapp nginx

The -d flag detaches the container to run in the background, -p 8080:80 maps host port 8080 to container port 80, and --mount source=myvol,target=/data attaches the named volume. All three stem requirements are satisfied in one command.

ConfigMap

ConfigMaps hold non-confidential key-value pairs decoupled from pod images, satisfying the stem's requirement for non-sensitive configuration such as a database hostname. Pods consume them as environment variables or mounted volumes, so configuration changes need no image rebuild. Secrets are reserved for confidential data, which the scenario explicitly excludes.

Run dependency scanning tools (e.g., Snyk) in the pipeline.

Dependency scanning inspects third-party libraries and their transitive dependencies for known CVEs before deployment, catching vulnerable packages that could leak credentials or data. This satisfies the stem's requirement for a practice preventing sensitive data exposure in the CI/CD pipeline.

Use environment variables to inject secrets at runtime.

Injecting secrets as environment variables at runtime keeps credentials out of committed source, image layers and build logs, so they are supplied only when the container starts. This satisfies the stem's requirement for a practice preventing sensitive data exposure in the pipeline.

Using a volume mount with a secret volume

A secret volume projects each key as a file in a tmpfs mount, so credentials never appear in environment variables or container stdout. This satisfies the constraint of avoiding exposure in logs, unlike envFrom or valueFrom, which surface values through the process environment.

LoadBalancer

The LoadBalancer Service type provisions an external cloud load balancer and assigns a public IP, routing traffic to the deployment's pods. This satisfies the requirement for external exposure, unlike ClusterIP (internal only) or NodePort (node IP and high port).

ENV NODE_ENV=production

ENV sets an environment variable inside the image and makes it available to subsequent build instructions and the running container, providing the default NODE_ENV value. ARG only applies at build time and is unavailable at runtime, so it cannot satisfy this requirement.

Use CSRF tokens in forms

CSRF tokens bind each state-changing form submission to the user's session, so a forged cross-site request lacks the unpredictable token and is rejected. This satisfies the stem's requirement for a security best practice in the web application.

Apply output encoding to prevent XSS

Output encoding converts characters such as < and > into inert HTML entities when rendering user-supplied data, so injected script is displayed as text rather than executed. This satisfies the stem's requirement for a security best practice preventing XSS.

Service

A Service assigns a stable virtual IP and DNS name, load-balancing traffic to pods selected by labels. Pods are ephemeral with changing IPs, so the Service abstraction provides the stable endpoint the scenario demands, unlike Deployments or bare pods.

input

The input directive pauses the stage and waits for human approval before continuing, which is precisely the manual gate required. It can specify approvers and a message, and blocks downstream stages until the response is submitted.