CCNA Application Deployment and Security Questions

HashiCorp Vault injects credentials dynamically at runtime, so no secret ever resides in source code or version control. This directly satisfies the stem's requirement to prevent hardcoded credentials, since applications authenticate to Vault and receive short-lived, rotated secrets instead of embedding static passwords or API keys.

Running as an unprivileged user means a process that escapes the application cannot perform root-only operations such as binding low ports, modifying system files, or loading kernel modules. This is one of the most effective single mitigations because most container escapes assume root inside the namespace. It directly limits the capabilities available after compromise.

HTTP Basic authentication transmits credentials in an easily decoded form, so confidentiality must come from the transport. TLS encrypts the entire request, including the Authorization header, between client and server. This is the standard and expected way to protect Basic credentials, and it also protects the response and any tokens exchanged during the session.

This is correct because environment variables are injected at runtime and are not part of the source code or repository. The application can read the token from os.environ without embedding it in code, and the platform can rotate the value without a code change. This satisfies the requirement to keep the token out of source control.

Environment variables supplied at runtime are injected into the container process when it starts and are not stored in any image layer, so the published image stays free of secrets. The application reads them through the normal process environment, and rotating a credential only requires restarting the container with a new value, which matches the stated requirement exactly.

Containers within a single pod share one network namespace, hence one IP address and port space, so the sidecar proxy and main application reach each other over localhost. This shared pod network model is exactly what the stem's localhost communication requires.

docker push uploads a locally tagged image and its layers to the configured registry repository, making it available for the colleague to pull. Commands such as docker save or docker commit do not transfer the image to a registry, so they fail the sharing requirement.

The host driver removes network namespace isolation, so the container binds directly to the host's interfaces and ports rather than receiving its own IP address. This satisfies the requirement for direct access to host interfaces, unlike bridge or overlay drivers, which assign separate addresses and require explicit port publishing.

Building the Docker image is the foundational pipeline step, converting source code and a Dockerfile into a runnable artefact. Without this stage, subsequent testing and registry push actions have no image to operate on, so it is essential in a containerised CI/CD workflow.

This is correct because an isolated, ephemeral build environment limits the persistence of any compromise. If an attacker compromises the build, the environment is destroyed after the run, so they cannot maintain access or tamper with future builds. It also prevents cross-contamination between pipeline runs and reduces the blast radius of a compromised build.

The Meraki Dashboard API authenticates requests with the X-Cisco-Meraki-API-Key header containing the API key. Supplying it in this header keeps the key out of the URL and query string. The endpoint for listing organizations then returns the organizations the key is authorized to access.

A ConfigMap stores non-confidential key-value configuration data and can be consumed as environment variables via envFrom or valueFrom. This keeps configuration out of the image and allows changes by updating the ConfigMap. It directly matches the requirement for database hostname and port values that are not sensitive.

DNA Center authentication uses a POST to the /dna/system/api/v1/auth/token endpoint with HTTP Basic authentication, returning a token used in the X-Auth-Token header. Reading credentials from environment variables keeps them out of source code and allows the same script to run in different environments without modification.

Minimal base images contain far fewer packages, libraries, and shells, which reduces the number of potential vulnerabilities and removes tools an attacker could use after gaining access. Fewer components mean fewer patch obligations and a smaller footprint. This is a widely recommended practice for shrinking container attack surface.

Publishing with `-p 8080:80` maps host port 8080 to container port 80, satisfying the requirement that external traffic on 8080 reaches the application listening internally on 80. The `-d` flag runs the container detached, so the terminal returns immediately while the web app keeps serving.

The -d flag detaches the container, -p 8080:80 maps host port 8080 to container port 80, and -v /host/data:/container/data mounts the host directory for persistence. Together these satisfy the detached, port-mapped, volume-mounted requirements in one command.

A ConfigMap stores non-confidential key-value data and can be mounted as a volume or exposed as environment variables. Mounting it at /etc/config lets the pod read app.conf from the expected path, and the same Deployment manifest can reference different ConfigMaps per cluster. This keeps environment-specific configuration out of the image, which is exactly what the scenario requires.

ClusterIP assigns a stable virtual IP reachable only from inside the cluster, exactly matching the internal exposure requirement. It load-balances HTTP traffic across the stateless pods via kube-proxy rules, without provisioning external load balancers or node ports. NodePort and LoadBalancer would expose the service externally, which the scenario does not request.

Docker caches each layer; if package.json and package-lock.json are copied first and npm install runs before the rest of the source is copied, that layer is reused unless the dependency manifests change. Copying all source first invalidates the cache on every code edit, forcing npm install to rerun. This ordering is the standard best practice for Node.js Dockerfiles.

LoadBalancer provisions an external cloud load balancer with a stable, routable IP that distributes traffic across the backing pods. ClusterIP is internal-only and NodePort exposes a high port on each node, neither meeting the stable external IP requirement.

With maxSurge: 1, the deployment may temporarily exceed the desired replica count by one pod, giving a ceiling of four. maxUnavailable: 0 guarantees all three original pods stay available throughout, so the surge pod is added alongside them rather than replacing any.

LoadBalancer provisions an external load balancer (typically via the cloud provider) that assigns a stable, externally reachable IP address. This IP remains consistent even if pods are rescheduled or nodes are replaced. It automatically routes traffic to the appropriate NodePort and ClusterIP, fulfilling the requirement for stable external access to the application.

A Kubernetes Secret stores sensitive data separately from the image and manifest, and it can be injected into a container as an environment variable using envFrom or valueFrom. This keeps the password out of the container image and out of the Deployment YAML. It is the standard mechanism for supplying runtime secrets in Kubernetes.

Storing the token in a .env file that is excluded via .gitignore keeps it out of the repository while still making it available to the script at runtime through python-dotenv. This separates configuration from code and prevents accidental exposure in commits. It is a standard local development pattern that preserves authentication functionality without hardcoding secrets.

Environment variables populated from a CI/CD secret store keep the key out of the repository and inject it only at runtime. The application reads the value without hardcoding it, and the pipeline masks the value in logs. This is the standard pattern for separating configuration and secrets from code in automated builds.

Signing images produces cryptographic proof of who built and published them. Enforcing verification at admission time, for example with a policy engine or cosign-backed admission controller, ensures only images with valid signatures from trusted publishers can run. This satisfies the requirement that only trusted images are deployed, even if an attacker compromises the registry.

Snyk scans third-party dependencies for known vulnerabilities, matching packages against a vulnerability database, which directly satisfies the pipeline's dependency-checking requirement. It integrates into CI/CD workflows and supports Python manifests such as requirements.txt and Pipfile, complementing the unit tests rather than replacing them.

Using a dedicated secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager) centralizes secret storage with encryption, access controls, and audit logging. Injecting secrets at runtime avoids embedding them in code or configuration files, reducing exposure. This is a best practice for secure secret management in CI/CD pipelines.

Patching requests.get with unittest.mock replaces the real network call with a controlled return value, so the test exercises the function's parsing and error handling without contacting the Meraki Dashboard API. This makes the test fast, deterministic, and safe to run in CI. It is the standard Python approach for isolating external HTTP dependencies in unit tests.

Publishing with 8080:5000 means the host listens on 8080 and forwards to port 5000 inside the container. The application is reachable only through 8080 on the host; host port 5000 is never bound by Docker, so a connection attempt there is refused. To reach the app on host port 5000 the mapping would need to be 5000:5000.

LoadBalancer provisions an external load balancer through the cloud provider, assigning a stable public IP that routes to the pods on your chosen port. This satisfies the stem's requirement for external traffic on a specific port, unlike ClusterIP (internal only) or NodePort (no stable external IP).

`kubectl describe pod my-pod` surfaces the pod's status conditions, container states and recent events, exposing scheduling failures, image pull errors or crash loops that stop it starting. This directly satisfies the troubleshooting constraint by revealing why the pod cannot launch, without requiring logs from a container that never ran.

emptyDir volumes are created when a pod is assigned to a node and exist for that pod's lifetime, shared by all containers within it. Because both containers mount the same emptyDir, they read and write the same filesystem, satisfying the requirement for intra-pod file sharing.

Parameterised queries send SQL code and user-supplied values separately, so input is bound as data rather than parsed as executable SQL. This structurally prevents injection, unlike escaping or validation, which can be bypassed by crafted payloads.

The Authorization header with the Bearer scheme is the standard way to transmit a token for OAuth 2.0 and many REST APIs. It clearly indicates the token type and is widely supported. Using this header ensures the API can validate the token and grant access to the requested resource.

Chaining commands with && in a single RUN creates one layer and allows cleanup of temporary files in that same layer, reducing image size. Each RUN creates a new layer, so separate commands leave intermediate files. This is a best practice for minimizing layers and cache efficiency.

Least privilege limits what an attacker can do with a stolen credential, even inside its validity window. If the identity can only push to one registry namespace or update one service, compromise does not yield broad access to other repositories or cloud resources, which is the core of reducing blast radius in this scenario.

Running tests before the push gate ensures only validated artefacts reach the registry. Building first produces the image under test; executing unit tests against it then permits the push stage to publish solely on success, preventing untested images from being distributed.

Parameterised queries send SQL code and user-supplied values to the database as separate constructs, so input is bound as data rather than parsed as executable SQL. This neutralises injection payloads by removing the mechanism attackers rely on, directly satisfying the requirement to prevent SQL injection within the application code.

This command executes netstat inside the running container and lists all TCP/UDP listening ports. Since the application may not be listening on the port declared in EXPOSE, checking the actual listening socket is the most direct way to identify a mismatch. It provides the ground truth needed to correct the port mapping or application configuration.

When services are attached to the same user-defined bridge network in Docker Compose, Docker's embedded DNS server automatically resolves service names to their container IPs. This allows the web service to connect to 'db' by hostname without manual linking or IP management. It is the recommended and simplest approach for service discovery in Compose.

The none network mode attaches no network interface beyond loopback, so the container cannot reach other containers or external hosts. This delivers the strongest isolation, satisfying the requirement of connecting to no network at all.

The client credentials grant is intended for machine-to-machine communication where the client authenticates with its own client ID and secret, with no end user involved. The server script can POST its credentials to the token endpoint and receive an access token directly. This matches the unattended execution requirement and the authorization server's supported grant exactly.

docker logs -f streams the container's stdout and stderr continuously, following new output as it is written, which is what real-time debugging of the database connection issue requires. The -f flag distinguishes it from a one-off dump of existing log entries.

Scanning the built image in the pipeline inspects the actual layers that would be pushed, detecting secrets wherever they were introduced, including base layers and hardcoded values. Configuring the scan stage to return a non-zero exit status on findings makes the pipeline fail before the push step executes, which is exactly the requested automatic gate.

EXPOSE 5000 documents that the container listens on port 5000 at runtime; it is metadata for image consumers and does not publish the port. This matches the requirement to document the Flask application's listening port.

The `-d` flag detaches the container, running it in the background, while `-p 8080:80` maps host port 8080 to container port 80, satisfying both stem constraints. The syntax `host:container` is critical here; reversing it would publish the wrong port. This single command therefore meets the detached-mode and port-mapping requirements exactly.

NodePort opens a static port on every cluster node, forwarding external traffic to the service's ClusterIP. This satisfies the requirement for exposing a service externally without a cloud load balancer, since kube-proxy listens on that port range (30000–32767) across all nodes.

CMD sets the default executable and parameters for a container, but is overridden entirely when arguments are supplied at runtime. It satisfies the stem's requirement for a startup command instruction, and pairs with ENTRYPOINT, which fixes the executable while CMD supplies default arguments.

ClusterIP assigns the Service a virtual IP reachable only from within the cluster, satisfying the requirement that the database be accessible to other pods but never exposed externally. NodePort and LoadBalancer would publish it beyond the cluster, and headless Services suit direct pod addressing rather than stable internal load balancing.

The -d flag detaches the container, returning the terminal immediately. The -p 8080:80 flag publishes host port 8080 and forwards it to container port 80, where nginx listens. Traffic to the host's 8080 reaches nginx inside the container.

Stage gates are approval or quality checkpoints between pipeline stages that halt progression when a condition fails. Placing a gate after integration tests prevents deployment to production on test failure, directly enforcing the required stop behaviour.

ConfigMaps hold non-sensitive configuration as key-value pairs, decoupled from pod images, so database hostnames can vary per environment without rebuilding containers. Secrets are reserved for sensitive data, making ConfigMap the appropriate resource for injection via environment variables or volumes.

The depends_on key establishes startup ordering, but adding the condition: service_healthy form makes Compose wait until the db service's healthcheck reports healthy before starting web. This satisfies the stem's requirement that web starts only after db is genuinely healthy, not merely launched.

docker logs -f streams a container's stdout and stderr, following output continuously. It retrieves runtime information about a container's processes, satisfying the requirement to view container information, though it requires a container name or ID.

The build key names the directory containing the Dockerfile, so Compose builds the image from that context rather than pulling a prebuilt one. Specifying image alone would only tag or fetch an existing image, failing the requirement to build from the current directory.

Configuring the deploy stage to depend on a successful security scan, and having the scan return a non-zero exit code on findings, causes the pipeline to halt before deployment. This enforces the gate automatically without manual intervention. It is the standard way to make quality checks mandatory in CI/CD.

Digital signatures bind the released artifact to a private key that only the trusted pipeline can use, so a stolen account credential alone cannot forge a valid release. Consumers who verify the signature reject artifacts not signed by the expected key. This provides the cryptographic guarantee that a compromised account cannot publish malicious code that passes verification.

Output encoding converts user-supplied characters into safe HTML entities before rendering, so injected script tags are displayed as text rather than executed. This directly neutralises the stored or reflected XSS vector described in the stem.

AppRole authentication requires exchanging a `role_id` and `secret_id` at the login endpoint for a Vault client token. That token is then presented in the `X-Vault-Token` header on subsequent requests. This is the documented flow and correctly separates authentication from secret retrieval, making it the right sequence for the CI job.

Terminating SSL/TLS at the reverse proxy decrypts incoming traffic there, then a redirect rule rewrites any HTTP request to HTTPS, so every client connection is forced onto TLS. This directly satisfies the requirement to enforce HTTPS across the web application.

Snyk scans manifest and lock files against vulnerability databases, flagging known CVEs in third-party packages and their transitive dependencies. This directly satisfies the pipeline's dependency vulnerability scanning stage, unlike SAST or container image scanning tools.

Restricting file permissions limits which local users can read the credentials, and excluding the file from version control prevents accidental commits that would expose secrets to anyone with repository access. Together these controls reduce the attack surface for a deployed configuration file. They complement, rather than replace, token-based authentication.

Namespaces partition a single cluster into logically isolated virtual clusters, so each team's objects, quotas and RBAC bindings stay scoped to their own boundary. This directly satisfies the stem's requirement that one team deploy applications without interfering with other teams sharing the same cluster.

A Secret of type kubernetes.io/tls stores a TLS certificate and private key and can be mounted as files into a pod via a volume. This keeps sensitive material out of the image and allows the application to read the files at a known path for mutual TLS. Other resources either store non-sensitive data or do not provide file-based injection.

Encrypted secret stores keep values out of the repository and mask them in logs, so pipeline output does not reveal them. Referencing them as variables allows jobs to consume secrets without hardcoding. This directly protects API keys and registry passwords during builds and deployments.

A PersistentVolumeClaim binds to a PersistentVolume, decoupling storage lifecycle from the pod so data survives pod deletion and rescheduling. This satisfies the stem's requirement for storage persisting beyond the pod lifecycle, unlike emptyDir or hostPath, which are tied to the pod or node.

This securityContext sets runAsNonRoot to true, which ensures the container does not run as UID 0, and readOnlyRootFilesystem to true, which mounts the root filesystem as read-only. These are the exact settings required to enforce the security policies. They can be applied at the pod or container level, but container-level is more granular.

The USER instruction sets the user name or UID that subsequent RUN, CMD, and ENTRYPOINT instructions run as. Placing USER appuser after creating the user ensures the container process starts without root privileges, which reduces the impact of a compromise and satisfies the requirement.

A Kubernetes Secret stores sensitive data such as passwords separately from Pod specifications and image contents, base64-encoded and mountable as environment variables or volumes. This keeps the database credential out of plaintext manifests, meeting the secure-storage requirement.

emptyDir creates a volume that exists for the pod's lifetime and is mounted into every container that requests it, so both containers read and write the same directory. It satisfies the shared local filesystem requirement, unlike hostPath, which ties the pod to a specific node.

The stages keyword groups jobs into named, ordered phases; GitLab CI runs each stage sequentially, so a build stage completes before a scan stage begins. This enforces the required build-then-scan order before pushing the image.

COPY transfers files from the build context into the image filesystem, so the Python source lands in the image. ADD also copies but additionally handles remote URLs and archive extraction, which the stem does not require.

The depends_on key expresses a startup dependency, so Docker Compose starts the db service before the web service. It controls start order only; the volume persists data independently, and healthchecks would add readiness gating beyond this requirement.

docker logs retrieves stdout and stderr from the specified container, and -f follows the stream so output continues as the container writes. Passing the container ID abc123 targets that exact container, satisfying the requirement to view its logs.