Back-end Web Developement Server Management Flashcards

24 sample cards from the Server Management deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

1. What is a Jenkinsfile and what are the two pipeline syntaxes?

   A Jenkinsfile is a text file (checked into source control) that defines a Jenkins Pipeline as code. The two syntaxes are Declarative Pipeline (structured, `pipeline { }` block) and Scripted Pipeline (Groovy-based, `node { }` block, more flexible/imperative).

2. In a Jenkins Declarative Pipeline, what are `stages` and `steps`?

   `stages` is a block containing one or more `stage` definitions representing distinct phases (e.g., Build, Test, Deploy). Each `stage` contains a `steps` block listing the individual commands/actions executed in that phase.

3. What is the Jenkins controller/agent (master/agent) architecture?

   The Jenkins controller (formerly master) schedules jobs, stores configuration, and serves the UI. Agents (nodes) are separate machines that execute the build jobs, distributing workload and allowing builds in different environments/OSes.

4. How can Jenkins jobs be triggered automatically on code changes?

   Via webhooks from the SCM (e.g., GitHub push triggers), SCM polling (`pollSCM` on a cron schedule), scheduled triggers (`cron`), or upstream/downstream job triggers. Webhooks are preferred as they are event-driven rather than polling.

5. What is GitHub Actions and what event-driven model does it use?

   GitHub Actions is a CI/CD and automation platform built into GitHub. Workflows are triggered by repository events (push, pull_request, schedule, etc.) defined in YAML files, running jobs on GitHub-hosted or self-hosted runners.

6. Where are GitHub Actions workflow files stored, and in what format?

   They are stored in the `.github/workflows/` directory of the repository as YAML files (`.yml`/`.yaml`). Each file defines one workflow.

7. Define the GitHub Actions hierarchy: workflow, job, step, and action.

   A workflow is the top-level automated process (one YAML file). A workflow contains jobs (run on a runner, parallel by default). Each job contains steps (sequential). A step runs either a shell command or an action — a reusable unit of code (e.g., `actions/checkout`).

8. In GitHub Actions, what does the `on` keyword specify, and give an example trigger.

   The `on` keyword specifies the event(s) that trigger the workflow. Examples: `on: push`, `on: pull_request`, `on: schedule` (cron), or `on: workflow_dispatch` (manual trigger).

9. By default, do jobs in a GitHub Actions workflow run in parallel or sequentially, and how do you make one wait for another?

   Jobs run in parallel by default. Use the `needs` keyword to declare dependencies so a job waits for the listed job(s) to complete successfully first (e.g., `needs: build`).

10. What is a GitHub Actions runner?

    A runner is the server/machine that executes a workflow's jobs. GitHub-hosted runners are managed by GitHub (fresh VM per job, e.g., `ubuntu-latest`); self-hosted runners are machines you provision and manage yourself, chosen with `runs-on`.

11. What does the `actions/checkout` action do in a GitHub Actions workflow?

    `actions/checkout` clones the repository's code onto the runner so subsequent steps can access and build it. Without it, the runner's workspace does not contain your source code.

12. What is GitLab CI/CD and what file configures it?

    GitLab CI/CD is the built-in continuous integration/delivery system of GitLab. It is configured by a `.gitlab-ci.yml` file in the repository root, which defines the pipeline's stages, jobs, and rules.

13. In GitLab CI, what is a pipeline and what are stages and jobs?

    A pipeline is the top-level component comprising stages that run in sequence. Each stage contains jobs that run in parallel. Jobs define the actual scripts/commands; if any job in a stage fails, later stages (by default) do not run.

14. What is a GitLab Runner?

    A GitLab Runner is the agent application that executes the jobs defined in `.gitlab-ci.yml`. Runners can be shared, group, or project-specific, and use executors (Docker, shell, Kubernetes, etc.) to run job scripts.

15. In GitLab CI, what is the purpose of the `stages` keyword and the default stages?

    The `stages` keyword defines the ordered list of stages and their execution sequence. If not defined, the default stages are `build`, `test`, and `deploy`, executed in that order.

16. In GitLab CI, what do `artifacts` and `cache` do, and how do they differ?

    `artifacts` are files/outputs a job produces that are passed to later stages/jobs and stored/downloadable after the pipeline (e.g., build outputs, reports). `cache` speeds up jobs by reusing files (e.g., dependencies) across pipeline runs. Artifacts move data forward within a pipeline; cache is for reuse across runs and is not guaranteed.

17. What is the conceptual difference between Continuous Integration (CI) and Continuous Deployment (CD)?

    CI is the practice of frequently merging code changes into a shared repository with automated build and test on each merge. Continuous Deployment automatically releases every passing change to production; Continuous Delivery keeps every change deployable but requires a manual approval to release.

18. Compare Docker and Kubernetes in one sentence each.

    Docker is a platform for building, packaging, and running individual containers on a host. Kubernetes is an orchestrator that manages, scales, and coordinates many containers across a cluster of hosts. They are complementary, not competitors.

19. What is a rolling update in Kubernetes and why is it useful?

    A rolling update incrementally replaces old Pods with new ones (a few at a time) rather than all at once, so the application stays available with zero downtime during a deployment. Kubernetes automatically rolls back or pauses if the new version fails health checks.

20. How do Kubernetes liveness and readiness probes differ?

    A liveness probe checks whether a container is still healthy; on failure Kubernetes restarts it. A readiness probe checks whether a container is ready to receive traffic; on failure the Pod is removed from Service endpoints (but not restarted).

21. What is the Horizontal Pod Autoscaler (HPA) in Kubernetes and what metric commonly drives it?

    The HPA automatically scales the number of Pod replicas up or down based on observed metrics, most commonly average CPU utilization. Conceptually the desired replica count is $\text{desired} = \left\lceil \text{current} \times \frac{M_{current}}{M_{target}} \right\rceil$, where $M$ is the metric value.

22. In Nginx, what does the `proxy_pass` directive do?

    `proxy_pass` forwards (proxies) a matched request to a specified backend server or upstream group, making Nginx act as a reverse proxy. Example: `proxy_pass http://backend;` inside a `location` block.

23. What is an Ingress in Kubernetes?

    An Ingress is an API object that manages external HTTP/HTTPS access to Services in a cluster, providing routing rules (host/path-based), TLS termination, and virtual hosting. It requires an Ingress controller (e.g., Nginx Ingress) to actually fulfill the rules.

24. What is the difference between Docker `COPY` and `ADD` instructions?

    `COPY` simply copies files/directories from the build context into the image. `ADD` does the same but additionally can extract local tar archives automatically and fetch files from remote URLs. Best practice favors `COPY` unless `ADD`'s extra features are specifically needed.

What this deck covers

Server Management flashcards FAQ