LFCA 128 🐧 LFCA Practice Questions — Domain 5
Domain 5, DevOps Fundamentals, is 12% of the LFCA exam—roughly 7 questions. It covers the practices and tools that bridge development and operations: CI/CD pipelines, Git version control, container fundamentals, and deployment environments. These are conceptual questions with a practical core. The exam tests whether you understand what continuous integration and continuous delivery mean, how Git tracks changes, what a container is and how it differs from a virtual machine, and what Kubernetes provides at a high level.
This chapter is a set of practice questions in the style of the LFCA exam. Each question presents a scenario and asks for the best answer among four choices. The answers are explained, and the distractors are identified so you can see why the wrong answers are wrong. The questions cover the specific competencies in Domain 5: DevOps basics and CI/CD, Git concepts, container basics, and orchestration.
Key point: Domain 5 is about the vocabulary and workflow of modern software delivery. It tests whether you can distinguish CI from CD, a commit from a push, an image from a container, and a pod from a deployment. The correct answer is the one that matches the definition and the stage of the workflow.
Why Domain 5 matters
The delivery problem. Software is not done when it compiles. It is done when it is running in production and delivering value. DevOps is the set of practices that make delivery reliable, repeatable, and fast. CI/CD, version control, containers, and orchestration are the tools that implement those practices.
The vocabulary problem. DevOps terminology is dense and often overlapping. Continuous integration, continuous delivery, and continuous deployment are three distinct things. A commit, a push, and a merge are three distinct Git operations. An image, a container, and a pod are three distinct abstractions. The exam tests whether you can keep them separate.
The workflow problem. DevOps is a workflow: code is written, committed, pushed, integrated, tested, built into an image, deployed, and monitored. Each stage has its own tools and its own concepts. The exam tests whether you know which stage a given tool or concept belongs to.
The container problem. Containers are the packaging format for modern applications. The exam tests the difference between an image and a container, the purpose of a Dockerfile, and the role of a registry. These are the fundamentals of containerized delivery.
The orchestration problem. A single container on a single host is simple. Managing dozens or hundreds of containers across a cluster requires orchestration. Kubernetes is the dominant orchestrator, and the exam tests its basic abstractions: pods, services, and deployments.
a. DevOps basics and CI/CD
Question 1. What is Continuous Integration (CI)?
A. Deploying code to production automatically
B. Merging code changes frequently and testing them automatically
C. Writing code continuously without breaks
D. Integrating multiple programming languages in one project
Answer: B. Continuous Integration is the practice of merging code changes into a shared branch frequently—often multiple times per day—and running automated tests on each merge. The goal is to detect integration problems early. Option A describes continuous deployment. Option C is not a technical practice. Option D describes polyglot development, not CI.
Question 2. What is the difference between Continuous Delivery and Continuous Deployment?
A. There is no difference
B. Continuous Delivery requires manual approval for production; Continuous Deployment does not
C. Continuous Deployment requires manual approval; Continuous Delivery does not
D. Continuous Delivery applies only to containers
Answer: B. Continuous Delivery means every change that passes the pipeline is ready to be deployed to production, but the deployment is triggered by a human decision. Continuous Deployment means every change that passes the pipeline is deployed to production automatically, with no human intervention. Option A is incorrect—they are distinct. Option C is the reverse. Option D is incorrect—both apply to any deployable artifact.
Question 3. Which of the following is a benefit of a CI/CD pipeline?
A. It eliminates the need for testing
B. It reduces the time between writing code and deploying it
C. It eliminates the need for version control
D. It guarantees that code has no bugs
Answer: B. A CI/CD pipeline automates the build, test, and deployment process, reducing the time from code commit to production. Option A is incorrect—testing is a core part of the pipeline. Option C is incorrect—version control is a prerequisite. Option D is incorrect—no pipeline can guarantee bug-free code.
Question 4. A development team wants to catch integration bugs as early as possible. Which practice should they adopt?
A. Deploy to production on every commit
B. Merge code frequently and run automated tests on each merge
C. Write all code in a single branch and merge at the end of the project
D. Skip testing in development and test only in production
Answer: B. Frequent merges with automated testing are the definition of Continuous Integration. The earlier a bug is found, the cheaper it is to fix. Option A is continuous deployment, which is a separate practice. Option C is the opposite of CI—long-lived branches delay integration. Option D defers bug detection to the most expensive stage.
b. Git concepts
Question 5. What does the git clone command do?
A. Creates a new branch
B. Copies a remote repository to the local machine
C. Commits changes to the local repository
D. Pushes changes to a remote repository
Answer: B. The git clone command copies a remote repository—including its history—to the local machine. Option A is git branch. Option C is git commit. Option D is git push.
Question 6. Which Git command records changes to the local repository?
A. git push
B. git commit
C. git pull
D. git clone
Answer: B. The git commit command records changes to the local repository. It creates a new commit with the staged changes and a message. Option A, git push, sends local commits to a remote repository. Option C, git pull, fetches and merges changes from a remote repository. Option D, git clone, copies a repository.
Question 7. What is the difference between git pull and git fetch?
A. There is no difference
B. git pull fetches and merges; git fetch only fetches
C. git fetch fetches and merges; git pull only fetches
D. git pull works only on branches; git fetch works only on tags
Answer: B. The git pull command fetches changes from the remote and merges them into the current branch. The git fetch command downloads changes from the remote but does not merge them; the changes are available locally but the working branch is unchanged. Option A is incorrect. Option C is the reverse. Option D is incorrect—both work on the repository, not just specific refs.
Question 8. A developer wants to work on a new feature without affecting the main codebase. What should they do?
A. Commit directly to the main branch
B. Create a new branch
C. Delete the main branch
D. Clone the repository again
Answer: B. Creating a new branch allows the developer to work on the feature in isolation. The main branch remains unchanged until the feature is complete and merged. Option A risks breaking the main branch. Option C is destructive and unnecessary. Option D creates a separate copy but does not isolate the work within the same repository.
Question 9. What is a merge conflict?
A. When two developers edit the same file in different branches and Git cannot automatically combine the changes
B. When a branch is deleted before merging
C. When a commit is pushed to the wrong remote
D. When a repository is cloned twice
Answer: A. A merge conflict occurs when changes in two branches affect the same lines of a file, and Git cannot determine which version to keep. The developer must resolve the conflict manually. Option B is a deletion, not a conflict. Option C is a push error. Option D is a duplication, not a conflict.
Question 10. Why is force pushing to a shared branch considered dangerous?
A. It is slower than a normal push
B. It can overwrite commits that other developers have based their work on
C. It requires administrator privileges
D. It deletes the branch
Answer: B. A force push replaces the remote branch’s history with the local history. If another developer has based work on commits that are removed by the force push, their work becomes inconsistent with the remote, and their next push may fail or overwrite. Option A is incorrect—speed is not the issue. Option C is incorrect—permissions are not the issue. Option D is incorrect—the branch is not deleted, but its history is rewritten.
c. Containers and orchestration
Question 11. What is the difference between a Docker image and a Docker container?
A. An image is running; a container is stopped
B. An image is a read-only template; a container is a running instance of an image
C. An image is stored in a registry; a container is stored locally
D. There is no difference
Answer: B. An image is a read-only template that contains the application and its dependencies. A container is a running instance of an image, with a writable layer on top. Option A is the reverse—containers run, images do not. Option C is partially true but not the defining difference. Option D is incorrect—they are distinct concepts.
Question 12. What is the purpose of a Dockerfile?
A. To store container data
B. To define the steps for building a Docker image
C. To run a container
D. To manage container networking
Answer: B. A Dockerfile is a text file with instructions for building a Docker image. Each instruction creates a layer in the image. Option A describes a volume. Option C describes docker run. Option D describes Docker networking commands.
Question 13. Where are Docker images typically stored and shared?
A. In a Dockerfile
B. In a container
C. In a registry
D. In a volume
Answer: C. A registry is a repository for Docker images. Docker Hub is the default public registry. Private registries can be hosted by organizations. Option A is the build recipe. Option B is a running instance. Option D is persistent storage.
Question 14. What is the primary difference between a container and a virtual machine?
A. Containers share the host kernel; virtual machines run a full guest OS
B. Containers require a hypervisor; virtual machines do not
C. Virtual machines are lighter than containers
D. Containers cannot be networked
Answer: A. Containers share the host operating system’s kernel and isolate processes using namespaces and cgroups. Virtual machines run a complete guest operating system on top of a hypervisor. This is why containers are lighter and start faster. Option B is the reverse—VMs require a hypervisor. Option C is the reverse—containers are lighter. Option D is incorrect—containers can be networked.
Question 15. In Kubernetes, what is a pod?
A. A physical server in the cluster
B. The smallest deployable unit, containing one or more containers
C. A persistent storage volume
D. A network load balancer
Answer: B. A pod is the smallest deployable unit in Kubernetes. It contains one or more containers that share the same network namespace and storage volumes. Option A describes a node. Option C describes a persistent volume. Option D describes a service or ingress.
Question 16. In Kubernetes, what is the purpose of a Service?
A. To store container images
B. To provide a stable network endpoint for a set of pods
C. To define the build steps for an image
D. To schedule pods on nodes
Answer: B. A Kubernetes Service provides a stable IP address and DNS name for a set of pods. Because pods are ephemeral, their IP addresses change; the Service provides a consistent endpoint that routes traffic to the current pods. Option A describes a registry. Option C describes a Dockerfile. Option D describes the scheduler.
Question 17. In Kubernetes, what is a Deployment?
A. A physical deployment of servers
B. A declarative specification for managing a set of pods
C. A container image
D. A network policy
Answer: B. A Kubernetes Deployment is a declarative specification that describes the desired state for a set of pods—how many replicas, which image, what configuration. The Deployment controller ensures the actual state matches the desired state. Option A is not a Kubernetes concept. Option C is an image. Option D is a network policy.
Question 18. Which command builds a Docker image from a Dockerfile?
A. docker run
B. docker build
C. docker pull
D. docker push
Answer: B. The docker build command builds a Docker image from a Dockerfile and a build context. Option A, docker run, creates and starts a container from an image. Option C, docker pull, downloads an image from a registry. Option D, docker push, uploads an image to a registry.
Complete Example Session
# ============================================
# PART 1: CI/CD
# ============================================
CI → merge frequently, test automatically
CD → deliver: ready to deploy, manual trigger
CD → deploy: deploy automatically
# ============================================
# PART 2: GIT
# ============================================
clone → copy remote repository
add → stage changes
commit → record changes locally
push → send commits to remote
pull → fetch and merge from remote
branch → create isolated line of work
merge → combine branches
# ============================================
# PART 3: CONTAINERS
# ============================================
Dockerfile → build recipe
Image → read-only template
Container → running instance
Registry → image storage and distribution
# ============================================
# PART 4: KUBERNETES
# ============================================
Pod → smallest deployable unit
Service → stable network endpoint
Deployment → declarative pod managementThe four parts summarized the concepts tested in Domain 5: CI/CD, Git, containers, and Kubernetes.
Quick Reference
CI/CD Stages
| Practice | Description | Trigger |
|---|---|---|
| Continuous Integration | Merge and test frequently | Every commit |
| Continuous Delivery | Ready to deploy | Manual approval |
| Continuous Deployment | Deploy automatically | Every passing build |
Git Commands
| Command | Purpose |
|---|---|
git clone | Copy remote repository |
git add | Stage changes |
git commit | Record changes locally |
git push | Send commits to remote |
git pull | Fetch and merge from remote |
git fetch | Fetch without merging |
git branch | Create or list branches |
git merge | Combine branches |
git checkout | Switch branches |
Container Concepts
| Concept | Description |
|---|---|
| Dockerfile | Build recipe |
| Image | Read-only template |
| Container | Running instance |
| Registry | Image storage |
| Volume | Persistent data |
| Port mapping | Host-to-container networking |
Kubernetes Abstractions
| Object | Purpose |
|---|---|
| Pod | Smallest deployable unit |
| Service | Stable network endpoint |
| Deployment | Declarative pod management |
| Node | Worker machine |
| Namespace | Logical cluster partition |
Best Practices
✅ Do This:
# Merge frequently to catch integration bugs early
CI: commit, test, merge # ✅
# Use branches for feature work
git checkout -b feature/new-thing # ✅
# Use commit messages that explain why
git commit -m "Fix timeout in payment gateway" # ✅
# Store images in a registry
docker push registry/image:tag # ✅
# Use specific image tags
image: nginx:1.27-alpine # ✅
# Use Deployments for stateless workloads
kubectl apply -f deployment.yaml # ✅❌ Don’t Do This:
# Don't force push to shared branches
git push --force origin main # ❌
# Don't commit directly to main in a team
git commit -m "quick fix" && git push origin main # ❌
# Don't use :latest in production
image: nginx:latest # ⚠️
# Don't store data inside containers
# (use volumes) # ❌
# Don't run containers as root
docker run --user root ... # ⚠️Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Confusing CI and CD | Both start with “C” | CI = integrate, CD = deliver |
| Confusing delivery and deployment | Both are “CD” | Delivery = manual, deployment = auto |
| Confusing pull and fetch | Both download | Pull = fetch + merge |
| Confusing image and container | Both are “Docker” | Image = template, container = instance |
| Confusing pod and deployment | Both are Kubernetes | Pod = unit, Deployment = manager |
| Force pushing shared branch | Convenience | Never force push shared branches |
Real-World Examples
1. CI Pipeline
On commit:
- Run linter
- Run unit tests
- Build artifact
- Report status2. CD Pipeline
On passing CI:
- Build image
- Push to registry
- Deploy to staging
- Await approval
- Deploy to production3. Git Feature Branch
git checkout -b feature/login
git add .
git commit -m "Add login form"
git push -u origin feature/login4. Git Pull Request
Push branch → open PR → review → merge5. Dockerfile
FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]6. Build and Push Image
docker build -t registry/app:1.0 .
docker push registry/app:1.07. Run Container
docker run -d -p 8080:80 registry/app:1.08. Kubernetes Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
template:
spec:
containers:
- name: web
image: registry/app:1.09. Kubernetes Service
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web
ports:
- port: 8010. Git Merge Conflict
<<<<<<< HEAD
current change
=======
incoming change
>>>>>>> feature/branch
Resolve manually, then commit.Visual
CI/CD Pipeline
┌─────────────────────────────────────────────────────────────┐
│ CI/CD PIPELINE │
│ │
│ Developer │
│ │ │
│ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Commit │───▶│ Build │───▶│ Test │───▶│ Image │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ CI: commit, build, test │
│ │
│ │ │
│ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Staging │───▶│ Approval│───▶│Production│ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ CD: deliver (manual) or deploy (automatic) │
│ │
└─────────────────────────────────────────────────────────────┘Git Workflow
┌─────────────────────────────────────────────────────────────┐
│ GIT WORKFLOW │
│ │
│ main ────●────●────●────●────●────●───▶ │
│ \ / │
│ feature ●────●────●────●─── │
│ │
│ 1. Branch from main │
│ 2. Commit changes │
│ 3. Push branch to remote │
│ 4. Open pull request │
│ 5. Review and merge │
│ │
│ Branches isolate work until it is ready to integrate. │
│ │
└─────────────────────────────────────────────────────────────┘Image vs Container
┌─────────────────────────────────────────────────────────────┐
│ IMAGE (read-only template) │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Layer 4: Application code │ │
│ │ Layer 3: Dependencies │ │
│ │ Layer 2: Runtime │ │
│ │ Layer 1: Base OS │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Stored in registry. Immutable. │
│ │
├─────────────────────────────────────────────────────────────┤
│ │
│ CONTAINER (running instance) │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Writable layer (ephemeral) │ │
│ │ ───────────────────────────────── │ │
│ │ Image layers (read-only, shared) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Running process. Disposable. │
│ │
└─────────────────────────────────────────────────────────────┘Kubernetes Abstractions
┌─────────────────────────────────────────────────────────────┐
│ KUBERNETES OBJECTS │
│ │
│ Deployment (manages desired state) │
│ │ │
│ ├── ReplicaSet │
│ │ │ │
│ │ ├── Pod [container] │
│ │ ├── Pod [container] │
│ │ └── Pod [container] │
│ │ │
│ └── Service (stable endpoint) │
│ │ │
│ └── Routes traffic to pods │
│ │
│ Pod: smallest unit, one or more containers │
│ Service: stable IP/DNS for a set of pods │
│ Deployment: declarative management of pods │
│ │
└─────────────────────────────────────────────────────────────┘Summary
| Topic | Key Distinction |
|---|---|
| CI | Merge frequently, test automatically |
| Continuous Delivery | Ready to deploy, manual trigger |
| Continuous Deployment | Deploy automatically |
git clone | Copy remote repository |
git commit | Record changes locally |
git push | Send commits to remote |
git pull | Fetch and merge |
git fetch | Fetch without merging |
| Branch | Isolated line of work |
| Merge conflict | Same lines changed in two branches |
| Image | Read-only template |
| Container | Running instance |
| Dockerfile | Build recipe |
| Registry | Image storage |
| Pod | Smallest deployable unit |
| Service | Stable network endpoint |
| Deployment | Declarative pod management |
Key takeaways:
- CI is about integration; CD is about delivery. Continuous Integration means merging and testing frequently. Continuous Delivery means the artifact is always ready to deploy. Continuous Deployment means it deploys automatically.
- Git commands have a specific order. Clone, branch, add, commit, push, pull request, merge. Each command operates on a different stage of the workflow.
git pullfetches and merges;git fetchonly fetches. - Branches isolate work. A feature branch allows development without affecting the main branch. The work is merged when it is complete and tested.
- Force pushing a shared branch is destructive. It rewrites history and can overwrite commits that others depend on. Never force push a branch that others are using.
- An image is a template; a container is an instance. The image is built from a Dockerfile, stored in a registry, and pulled to a host. The container is created from the image and runs as a process.
- Kubernetes has three core abstractions. A pod is the smallest deployable unit. A service provides a stable network endpoint. A deployment manages the desired state of a set of pods.
- Containers share the host kernel; VMs run a full guest OS. This is why containers are lighter, faster to start, and more densely packed. VMs provide stronger isolation.
Remember: Domain 5 is about the workflow of modern software delivery. It tests whether you understand the stages—code, commit, build, test, image, deploy—and the tools that implement each stage. The questions are scenario-based: a team wants to catch bugs early, which practice should they adopt? A developer wants to work on a feature without affecting main, what should they do? The correct answer is the one that matches the stage and the tool. If you know the vocabulary—CI, CD, commit, push, image, container, pod, service, deployment—the domain is straightforward.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!