Skip to content
tezvyn:

Top 30 Intermediate DevOps & Cloud Concepts Quiz

30 intermediate multiple-choice DevOps & Cloud concept questions, the mechanics underneath the basics: how the pieces relate and where the usual mental model stops holding. They come from 30 bites in the DevOps & Cloud library, the middle slice of the 619 DevOps & Cloud concept questions in the library. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.

Infrastructure, containers, CI/CD, and cloud

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

  1. Question 1 of 30

    Which statement accurately describes a key characteristic of Linux namespaces?

    Show the answer

    Answer: c · They enable processes to have isolated views of system resources while sharing the host's single kernel.

    Linux namespaces provide isolated environments for resources like process IDs and network interfaces, but they all share the host's single kernel. This is a fundamental difference from virtual machines, which run their own independent kernels. The card explicitly states that namespaces are not a sole security boundary for untrusted code.

    Read the full bite: Linux Namespaces: A Virtual Slice of the OS

  2. Question 2 of 30

    What does it signify if an SRE team consistently operates well within its allocated error budget?

    Show the answer

    Answer: b · The team is being overly cautious, potentially sacrificing innovation for unnecessary stability.

    The card explicitly states that having too much error budget left over signals being "too conservative and slowing innovation," indicating that resources might be better spent on new features or calculated risks. Option D is tempting but incorrect because the card notes that users often cannot perceive the difference between high and extreme reliability, making excessive investment in stability pointless.

    Read the full bite: Embracing Risk: Reliability Is a Budget, Not a Goal

  3. Question 3 of 30

    Which scenario best demonstrates the appropriate use of an artifact repository?

    Show the answer

    Answer: a · Publishing a newly built Java .jar file to be consumed by other internal projects.

    An artifact repository is designed to store and share binary outputs like compiled code (.jar files) from a build process for consumption by other systems or teams. Storing source code is for version control systems, while archiving unstructured logs or serving static assets are roles for general file storage or web servers, not artifact repositories.

    Read the full bite: Artifact Repository: Your CI/CD's Private Library

  4. Question 4 of 30

    What is the primary problem that Linux cgroups were designed to solve in a multi-tenant server environment?

    Show the answer

    Answer: c · Preventing a single application from consuming all available CPU or memory, thus starving other processes.

    The card explicitly states that cgroups were introduced because 'a single runaway process could consume all available CPU or memory, starving every other process and crashing the system.' While cgroups are related to container isolation, their primary role is resource limiting, not network traffic isolation or secure communication.

    Read the full bite: Linux cgroups: Resource Fences for Processes

  5. Question 5 of 30

    Which characteristic is most crucial for an effective Service Level Indicator (SLI)?

    Show the answer

    Answer: c · It directly reflects the user's experience or perception of service performance.

    The card explicitly states that an effective SLI measures what matters to the user, focusing on their experience rather than internal system metrics. Option D describes a common pitfall, as system metrics are causes, not symptoms felt by users, and should not be primary SLIs.

    Read the full bite: Service Level Indicators: Measuring What Matters

  6. Question 6 of 30

    What is the typical immediate consequence when a service's error budget is exhausted?

    Show the answer

    Answer: c · All non-essential feature releases are temporarily halted to prioritize reliability work.

    The card states that exhausting the error budget typically triggers a freeze on non-essential releases, redirecting focus to reliability work. The Service Level Objective (SLO) is the target from which the budget is derived; exhausting the budget means the service is failing to meet the SLO, not that the SLO itself should be changed.

    Read the full bite: Error Budgets: Balancing Reliability and Innovation

  7. Question 7 of 30

    Which component in a Kubernetes node is directly responsible for pulling container images and setting up their isolated execution environment?

    Show the answer

    Answer: a · The container runtime, which executes containers based on instructions from the kubelet

    The container runtime is the low-level engine that directly pulls images and creates isolated container environments using features like namespaces and cgroups. The kubelet acts as a 'transmission,' translating Kubernetes commands into instructions for the runtime, but does not perform the execution itself.

    Read the full bite: Container Runtime: The Engine That Runs Your Containers

  8. Question 8 of 30

    What is the primary problem Infrastructure as Code (IaC) aims to solve in managing IT infrastructure?

    Show the answer

    Answer: a · Preventing configuration drift and ensuring consistent, repeatable environments.

    The card explicitly states IaC was created to combat 'configuration drift' and ensure 'consistent, repeatable environments.' While IaC can contribute to cost efficiency, its main purpose is not cost reduction, and it does not eliminate all human involvement, but rather automates the provisioning process through code, not GUIs.

    Read the full bite: Infrastructure as Code: Manage Servers with Code, Not Clicks

  9. Question 9 of 30

    A team avoids public Docker images in their non-Docker runtime, believing the format is proprietary to Docker. Which statement corrects this misunderstanding?

    Show the answer

    Answer: a · Docker images are OCI-compliant bundles that run on any compliant runtime without conversion.

    The card calls this belief a footgun, emphasizing that Docker images are OCI-compliant bundles executable by any compliant runtime, much like USB-C devices work with any compliant charger. Option C invents a translation step that the standard eliminates, and option B confuses interface compatibility with performance guarantees.

    Read the full bite: OCI: The USB-C of Containers

  10. Question 10 of 30

    Which core principle defines the 'blameless' approach in a postmortem?

    Show the answer

    Answer: b · Human errors are symptoms of systemic issues, and everyone involved acted with good intentions.

    The card explicitly states that a blameless postmortem 'assumes that everyone involved in an incident acted with good intentions' and 'treats human error not as the cause of failure, but as a symptom of a deeper, systemic issue.' Option A describes a blame-focused approach, which is the antithesis of a blameless postmortem.

    Read the full bite: Blameless Postmortems: Fix Systems, Not Blame

  11. Question 11 of 30

    What is the primary advantage of implementing a Blue-Green deployment strategy?

    Show the answer

    Answer: d · It ensures continuous service availability and provides immediate rollback capabilities during deployments.

    The card states that Blue-Green deployment enables "zero-downtime releases and instant rollbacks," which directly translates to continuous service availability and immediate rollback. Option C is incorrect because this strategy temporarily doubles infrastructure costs.

    Read the full bite: Blue-Green Deployment: Zero-Downtime Releases

  12. Question 12 of 30

    What is the primary distinction between a canary release and A/B testing?

    Show the answer

    Answer: a · A canary release primarily validates the technical stability and performance of a new version, whereas A/B testing evaluates user engagement and business outcomes.

    The card states that a canary's goal is to quickly validate stability, while an A/B test is a longer-running experiment to test a business hypothesis. Option B describes a feature of canary releases but not its primary distinguishing purpose from A/B testing.

    Read the full bite: Canary Release: Test New Code on Real Users, Safely

  13. Question 13 of 30

    Which scenario best illustrates the primary financial advantage of adopting a cloud-based OpEx model compared to traditional CapEx?

    Show the answer

    Answer: c · A startup needing to quickly deploy a new service with fluctuating user demand without significant upfront hardware purchases.

    Option C is correct because the OpEx model allows startups to avoid large upfront hardware purchases and enables rapid scaling for fluctuating demand, directly aligning with the financial advantages described. Option D is a tempting distractor, but the card explicitly states that pure OpEx can be more expensive for predictable, stable workloads over the long term, meaning it doesn't always guarantee overall cost reduction.

    Read the full bite: CapEx vs. OpEx: The Cloud's Financial Shift

  14. Question 14 of 30

    Which cloud strategy combination best addresses predictable monthly user growth and unpredictable, short-duration traffic spikes?

    Show the answer

    Answer: b · Implement scalability for the monthly growth and elasticity for the celebrity-induced spikes.

    Scalability is ideal for planned, long-term growth, while elasticity efficiently handles unpredictable, short-term demand fluctuations by automatically adjusting resources. Relying only on elasticity for steady growth is inefficient, as it would constantly make small adjustments instead of operating from a stable baseline.

    Read the full bite: Cloud Scalability vs. Elasticity: Planned Growth vs. Real-Time Reaction

  15. Question 15 of 30

    Which principle is central to High Availability's ability to maintain continuous service during component failures?

    Show the answer

    Answer: a · Implementing redundant components with automatic failover mechanisms to handle detected outages.

    The core of High Availability involves having redundant components and automatically rerouting traffic to a healthy standby when a primary component fails. Distractor B is incorrect because HA specifically emphasizes automatic failover, not manual intervention.

    Read the full bite: High Availability: Designing Systems That Don't Go Down

  16. Question 16 of 30

    The cloud's Region/Availability Zone (AZ) model is primarily designed to address which of the following challenges?

    Show the answer

    Answer: b · The inherent risk of a single data center becoming a critical point of failure.

    The card states that "A single data center is a massive single point of failure" and the Region/AZ model was created to allow applications to "survive the loss of an entire data center or more." This directly addresses the risk of single data center failures. While other options are general cloud benefits, they are not the primary design goal of the Region/AZ model's failure isolation.

    Read the full bite: Cloud Regions and AZs: Infrastructure Built for Failure

  17. Question 17 of 30

    Which statement accurately describes a limitation of the Four Golden Signals?

    Show the answer

    Answer: c · They do not provide sufficient detail for identifying the root cause of an issue.

    The card explicitly states that the Golden Signals 'tell you that a problem exists... but not necessarily why,' requiring deeper metrics for root cause analysis. Option B is incorrect because they focus on user experience, and options B and C misrepresent their purpose and applicability.

    Read the full bite: The Four Golden Signals of Service Monitoring

  18. Question 18 of 30

    Under the Shared Responsibility Model, which security task is always the customer's responsibility, regardless of the cloud service model (IaaS, PaaS, or SaaS)?

    Show the answer

    Answer: b · Managing user access and data within the service

    The card explicitly states that customers always retain responsibility for their data, accounts, and access management, which includes managing user access and data within the service. Patching the guest operating system (option A) is only the customer's responsibility in IaaS, with the provider handling it in PaaS and SaaS.

    Read the full bite: The Cloud's Shared Responsibility Model

  19. Question 19 of 30

    What fundamental problem are Docker Volumes primarily designed to solve?

    Show the answer

    Answer: a · The loss of data written inside a container's filesystem when the container is removed.

    Docker Volumes exist because data written directly into a container's filesystem is lost when the container is removed, which is problematic for stateful applications. Option D describes the ephemeral nature of containers, which is the problem volumes counteract, not what they provide.

    Read the full bite: Docker Volumes: Persistent Data for Ephemeral Containers

  20. Question 20 of 30

    For multi-service applications on a single host, why are user-defined bridge networks preferred over the default bridge network?

    Show the answer

    Answer: b · They provide an internal DNS service for containers to resolve each other by name.

    The card explicitly states that user-defined bridge networks are superior because they provide an internal DNS service, allowing containers to find each other by name, which is essential for multi-service applications. The default bridge network lacks this feature, making it brittle due to changing IP addresses.

    Read the full bite: Docker Networking: How Containers Talk to Each Other

  21. Question 21 of 30

    Which scenario most strongly favors implementing a push-based metrics collection system?

    Show the answer

    Answer: a · An application deployed as a serverless function that executes for a very short duration.

    The card states that push is ideal for "short-lived or ephemeral workloads like serverless functions or batch jobs, as they might terminate before a pull-based scraper can reach them." Option D describes a risk of push systems (the 'thundering herd' problem), not a reason to favor them.

    Read the full bite: Pull vs. Push: How Your Metrics Get to the Collector

  22. Question 22 of 30

    What is the primary role of a Pull Request in a team's software development workflow?

    Show the answer

    Answer: c · To provide a formal mechanism for discussing, reviewing, and approving code changes before integration.

    The card emphasizes that a Pull Request is a "structured conversation about a proposed code change" and exists "to create a formal, collaborative process for proposing, discussing, and reviewing code changes." While merging is the ultimate goal, the core purpose is the review and discussion. Option B is a tempting distractor because merging is the outcome, but it misses the crucial review and approval steps.

    Read the full bite: Pull Requests: A Structured Conversation About Code

  23. Question 23 of 30

    To maximize Docker build cache efficiency, how should Dockerfile instructions be ordered?

    Show the answer

    Answer: c · Arrange instructions from least frequently changing to most frequently changing, top to bottom.

    The card advises placing infrequently changing instructions at the top and frequently changing ones as late as possible to optimize cache. Placing frequently changing instructions early, as in option D, is identified as a 'footgun' that invalidates the cache for subsequent steps unnecessarily.

    Read the full bite: Docker Build Cache: Don't Rebuild What Hasn't Changed

  24. Question 24 of 30

    When integrating a feature branch into the main branch using git merge, what is the most significant characteristic of the resulting history?

    Show the answer

    Answer: c · A new commit is generated on the target branch, explicitly recording the point where two distinct development lines converged.

    The card explains that git merge creates a "new, single commit that formally joins these two timelines" and acts as "a knot, holding the two threads together by having two parents." This merge commit explicitly records the convergence of distinct development lines. Option D describes git rebase, which rewrites history to create a linear sequence of commits, unlike git merge which preserves the parallel history.

    Read the full bite: Git Merge: Combining Development Histories

  25. Question 25 of 30

    When an application scales by adding new servers, how does a cloud load balancer ensure these new servers are utilized?

    Show the answer

    Answer: b · It detects the new servers via health checks and includes them in its traffic distribution.

    The card states that the load balancer "automatically detects these new instances, passes its health checks, and begins routing a share of the incoming HTTP requests to them." This ensures new servers are utilized. Option C is incorrect because the load balancer manages the backend server pool internally, not by updating DNS for individual backend servers.

    Read the full bite: Cloud Load Balancer: Your App's Traffic Cop

  26. Question 26 of 30

    What is the primary function of a .dockerignore file in a Docker project?

    Show the answer

    Answer: d · To prevent specific files from being included in the build context sent to the Docker daemon.

    The .dockerignore file's main role is to instruct the Docker client to omit specified files and directories from the build context before it's archived and sent to the daemon. While this can lead to smaller final images (C) if those files would have been copied, its direct and primary function is to filter the build context itself, improving build speed and security.

    Read the full bite: The .dockerignore File: Keep Your Build Context Lean

  27. Question 27 of 30

    Which of the following best describes the primary function of an Auto Scaling Group (ASG)?

    Show the answer

    Answer: d · To dynamically adjust the number of instances based on demand and automatically replace failed instances.

    The card explicitly states ASGs automate both 'elasticity (matching capacity to demand)' and 'fault tolerance (recovering from instance failures),' which aligns with dynamically adjusting instance count and replacing failed instances. Option C describes the function of a load balancer, which works in conjunction with an ASG but is not the ASG's primary role.

    Read the full bite: Auto Scaling Groups: Elasticity and Self-Healing

  28. Question 28 of 30

    What is the primary reason to avoid rebasing a branch that other developers have already pulled?

    Show the answer

    Answer: c · It rewrites history, forcing teammates into complex manual repository fixes due to conflicting histories.

    The card explicitly states that rebasing a shared branch rewrites its history, causing conflicts with teammates' local histories and forcing them into complex manual fixes. This is the 'absolute rule' for when not to use it. Distractor B is incorrect because rebase aims to create a more linear history.

    Read the full bite: Git Rebase: Rewriting History for a Cleaner Timeline

  29. Question 29 of 30

    When would an AWS customer most likely choose a Convertible Reserved Instance over a Standard Reserved Instance?

    Show the answer

    Answer: b · If they foresee potential changes in their instance family or operating system requirements.

    Convertible RIs offer flexibility to change instance families or operating systems later, making them suitable when future requirements are uncertain. Standard RIs, while offering the highest discount, lack this flexibility, making option A incorrect.

    Read the full bite: AWS Reserved Instances: Commit to Compute, Save Big

  30. Question 30 of 30

    Which property of annotated tags makes them the correct choice for production release markers?

    Show the answer

    Answer: d · They include tagger identity, timestamps, and optional GPG signatures for verification.

    Annotated tags are full objects containing tagger identity, timestamps, and optional GPG signatures, providing the audit trail required for production releases. Option B incorrectly assigns the properties of lightweight tags to annotated tags; lightweight tags are merely simple refs that lack metadata and auditability.

    Read the full bite: Git Tags: Immutable Milestones for Release History

Could you explain these out loud?

That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon