CCNA Application Deployment and Security Questions

By default many images run as root, so a compromised process would hold root privileges inside the container namespace and could exploit any kernel or mount weakness. Specifying a non-root user in the image or at run time removes that privilege. It directly reduces what an attacker can do after a successful compromise, which is exactly the goal of the review.

Vault stores credentials outside the repository and injects them at deploy time, so secrets never appear in source code, pipeline definitions or image layers. This removes hardcoded credentials from the codebase, satisfying the stem's security requirement.

A NetworkPolicy with a default-deny posture and explicit allow rules segments the network so a compromised pod cannot reach unrelated workloads. It is the native Kubernetes mechanism for pod-level network segmentation. Applying it to the API deployment restricts lateral movement, which is exactly the segmentation goal described in the scenario.

Pointing verify at a PEM file containing the certificate or its issuing CA lets the requests library build a trust chain for that specific server. Validation remains fully enforced, so a mismatched hostname or an untrusted certificate still fails. This is the standard way to trust a self-signed certificate without weakening TLS verification for the connection.

The push trigger with a branches filter limited to main runs the workflow only on commits pushed to that branch, satisfying the stated condition. Pull request events and pushes to other branches will not trigger the build-and-push job.

The on-failure restart policy restarts the container only when it exits with a non-zero code, matching the requirement precisely. Unlike always, it avoids restarting after clean exits; unlike unless-stopped, it does not persist across daemon restarts.

The pause subcommand halts the Deployment controller's reconciliation, freezing the current ReplicaSets so no further pods are rolled out while failing health checks are investigated. This directly satisfies the requirement to stop further updates during the failing rollout.

Kubernetes Secrets are designed to hold confidential data such as passwords and tokens. Mounting them as volumes avoids exposing them in environment variables or image layers. This limits access to only the containers that need them and supports encryption at rest if configured. It is a recommended practice for protecting sensitive information in Kubernetes.

A `.dockerignore` file excludes matching paths from the build context sent to the Docker daemon, so `COPY . /app` will not include `.env` or `.git`. This is the standard, declarative way to keep secrets and repository metadata out of an image without altering application logic. It also speeds up builds by reducing context size, and it works regardless of the base image or runtime.

ARG declares build-time variables that persist only during image construction, so the version can be passed via --build-arg without editing the Dockerfile. ENV would bake the value permanently into the image, failing the requirement that it change without modifying the Dockerfile.

Running unit tests directly after building the image validates code quality before the artefact is pushed to the registry, satisfying the stem's requirement to catch defects prior to publication. Deploying or pushing first would propagate unverified code, defeating the quality gate.

ConfigMap is designed to store non-confidential configuration data in key-value pairs. It can be consumed by pods as environment variables, command-line arguments, or configuration files in a volume. This allows updating configuration without rebuilding the container image, exactly matching the requirement.

Keeping secrets in a .env file excluded from version control prevents credentials entering Git history, while environment variables inject them at runtime without hardcoding. This satisfies the pipeline's need to avoid exposing secrets in source repositories.

`volumes` is a valid top-level key, declaring named volumes that services reference for persistent storage. It satisfies the stem's requirement for legitimate Compose file sections, sitting alongside `services` and `networks` as a root-level declaration rather than a service-level sub-key.

`kubectl apply -f deployment.yaml` reads the manifest from the named file and applies its declared state to the cluster, satisfying the requirement to deploy from a file. The `-f` flag specifies the file path, while `apply` performs a declarative create-or-update, unlike imperative `create` or `run`.

GitHub Actions reads workflow YAML files from .github/workflows in the repository itself, letting jobs run tests then conditionally build and push the image using needs or if conditions. No external CI server configuration is required, matching the stem's directory constraint.

Reading from environment variables keeps secrets out of the codebase and lets each environment supply its own values. A locally stored, git-ignored .env file provides convenience during development while CI runners inject values through their secret stores. This pattern adapts to both contexts without code changes and avoids leaking credentials into version history.

Parameterised queries separate SQL code from user-supplied values, so input is treated as data rather than executable SQL. This neutralises injection payloads because the database parses the statement before binding parameters, unlike string concatenation or escaping.

A manual approval gate inserted before the production deploy stage halts the pipeline so a human verifies build and test results before release. This directly prevents a faulty build from reaching production, whereas earlier automated stages may pass flawed artefacts through.

A Dockerfile declaratively defines the base image with the Python version, the package installations, and the application code copy, producing an image that runs the same way everywhere Docker is available. Building the same Dockerfile on an engineer's machine and on the CI runner yields consistent environments, which is precisely the repeatable isolation requested.

`kubectl set image` patches the Deployment's pod template in place, changing the container image to myapp:v2. This mutation triggers the Deployment controller to create a new ReplicaSet and roll pods gradually, satisfying the rolling update requirement without editing YAML or recreating the Deployment.

curl localhost:8080 connects to port 8080 on the loopback interface, which the firewall permits for local traffic. The published port forwards to container port 80, so the engineer can verify the nginx web server without external access.

Exposes service on each Node's IP at a static port.

docker logs -f web retrieves the container's stdout and stderr, revealing why the process exited, such as a crash or misconfiguration. Since the container started detached and failed, logs are the primary diagnostic, unlike docker ps which only shows status.

The -t flag assigns the repository name and tag myapp:v1 to the built image, while the trailing dot supplies the build context (current directory) containing the Dockerfile. Without -t the image would be untagged, so this satisfies the tagging requirement precisely.

A Secret mounted as a volume keeps the value out of the image and out of the pod specification, and kubelet refreshes the projected files when the Secret is updated. Having the application re-read the file per request means rotation takes effect without a rebuild or redeploy, satisfying all three constraints in the scenario.

The -f (follow) flag streams new log output continuously rather than printing existing logs and exiting, which is exactly the real-time behaviour required. Plain docker logs without -f returns a static snapshot and would not satisfy the live-streaming requirement.

Parameterized queries with prepared statements separate SQL code from user-supplied data, so input is treated as a value rather than executable SQL. This prevents attackers from injecting malicious clauses, satisfying the requirement to stop SQL injection.

Secrets store sensitive configuration data, such as passwords, tokens and certificates, separately from pod images and inject it at runtime as environment variables or mounted volumes. This satisfies the stem's requirement for a configuration-data resource, complementing ConfigMaps for non-sensitive values.

EXPOSE is documentation only: it records that the image's process listens on port 5000, but publishes nothing. The port becomes reachable only when mapped at runtime with docker run -p, satisfying the stem's distinction between declaring and publishing.

CMD sets the default executable for the container, supplying the command that runs at startup. Placed last, it defines the Python application's launch process, and unlike ENTRYPOINT it can be overridden at runtime with docker run arguments.

Unit tests execute immediately after the build stage, validating individual code units before the artefact progresses toward deployment. This enforces the code-quality gate described in the stem, catching defects earlier than integration or deployment stages would.

This is correct because CI/CD systems treat a non-zero exit code from a step as a failure, which stops the pipeline and prevents the vulnerable image from being published. Setting the scanner's severity threshold to critical and letting it return a failing exit code enforces the gate automatically without manual review.

Environment variables allow secrets to be injected at runtime without being stored in code or committed files. This separates configuration from code and is a widely accepted practice. The application reads the key from the environment, and the value can be set by the deployment environment, CI/CD system, or orchestration platform, reducing the risk of accidental exposure.

GitHub Secrets store credentials encrypted and inject them at runtime via the secrets context, so the registry password never appears in workflow files or logs. Referencing ${{ secrets.REGISTRY_PASSWORD }} keeps the value masked and out of version control.

Detached mode starts the services and immediately returns control to the terminal, leaving containers running in the background rather than streaming their logs. This satisfies the stem's requirement to explain what the -d flag does for the multi-service application.

depends_on declares startup and shutdown ordering between services, so Compose starts the named dependency first. It satisfies the stem's requirement for defining dependency order, unlike links or restart, which govern connectivity or restart behaviour rather than sequencing.

Separating the stages and gating the push on test success ensures that a failing test halts the pipeline before the image is published. This prevents broken artifacts from reaching the registry and gives clear feedback about which stage failed. It is the standard way to enforce quality gates in CI/CD.

Parameterised queries with prepared statements send SQL structure and user input separately, so input is bound as data and never parsed as executable SQL. That mechanism neutralises injection regardless of input content, satisfying the secure-coding requirement more reliably than escaping or validation alone.

mTLS requires the client to validate the server certificate chain. Trusting the private CA allows the client to verify the chain, and setting the expected server name enforces hostname verification against the certificate's subject alternative name. This provides both chain validation and identity binding, which is exactly what the scenario requires.

A digest is a cryptographic hash of the image manifest, so referencing it pins the exact bits that were reviewed. Docker Content Trust uses signing keys to verify that the publisher authorized the image before it is pulled. Together they prove the running container matches the approved artifact and that it was not tampered with in transit or in the registry.

This is correct because an Ingress resource can terminate TLS by referencing a TLS secret, and a certificate manager such as cert-manager can automatically provision and renew that secret. The Ingress routes external traffic to the Service, and the TLS section enables HTTPS on port 443. This matches the requirement for automatic certificate management.

Docker's default bridge network provides no automatic DNS resolution between containers, so each container must address the other by its assigned IP address. Container names resolve only on user-defined bridge networks, making IP addresses the sole default identifier here.

Snyk and Dependabot inspect manifest and lock files against vulnerability databases, surfacing known CVEs in third-party libraries and transitive dependencies. This satisfies DevSecOps by shifting dependency risk detection into the build pipeline before deployment, rather than relying on runtime protection alone.

GitHub Actions can issue a short-lived OIDC token that AWS IAM trusts via a configured identity provider. The workflow assumes an IAM role and receives temporary credentials, eliminating long-lived keys. This satisfies the prohibition, supports fine-grained trust conditions such as repository and branch, and automatically expires credentials, reducing the risk of credential leakage.

The services section in a Docker Compose file defines each container as a service, specifying the image, ports, environment variables, volumes, and dependencies. It is the core building block for multi-container applications, allowing containers to be networked together and managed as a single unit. This directly addresses the need to define the database and web server containers.

Docker push requires the local image tag to match the remote repository path, including the namespace. Retagging as devopsuser/webapp:latest creates that qualified reference, and the subsequent push targets the same repository. Without the namespace prefix, the daemon would attempt to push to an implicit library repository and fail authentication or not find the target.

API keys should be scoped to the minimum required permissions and rotated periodically to limit the impact of a compromised key. This follows the principle of least privilege and reduces the window of exposure, making it a core security practice for Intersight API access.