아무것도 놓치고 싶지 않으신가요?

인증 시험 합격 팁

최신 시험 소식 및 할인 정보

전문가가 선별하고 최신 정보를 제공합니다.

예, 뉴스레터를 보내주세요

다른 면접 문제 보기

1
참고 답변
To optimize a CI/CD pipeline for faster deployments, focus on reducing build times, improving test efficiency, and automating deployments while maintaining reliability. Caching dependencies, Docker layers, and artifacts helps avoid unnecessary rebuilds, significantly improving speed. Using parallel execution for running unit, integration, and functional tests ensures that different test stages don't slow down the pipeline. Implementing incremental builds, where only modified components are recompiled instead of the entire application, also speeds up the process. Containerization with Docker and orchestration with Kubernetes allows consistent and rapid deployments across environments. Reducing the number of stages in the pipeline and executing non-critical steps asynchronously can further streamline execution. Setting up blue-green or canary deployments minimizes downtime and rollback risks.
2
참고 답변
The Container Network Interface (CNI) is an API specification that is focused around the creation and connection of container workloads. CNI has two main commands: add and delete. Configuration is passed in as JSON data. When the CNI plugin is added, a virtual ethernet device pair is created and then connected between the Pod network namespace and the Host network namespace. Once IPs and routes are created and assigned, the information is returned to the Kubernetes API server. An important feature that was added in later versions is the ability to chain CNI plugins.
커리어 가속

자격증을 취득하여 이력서를 돋보이게 하세요.

데이터 분석에 따르면 IT 자격증 보유자의 연봉은 평균 구직자보다 26% 높습니다. SPOTO에서 자격증 취득과 면접 준비를 동시에 진행하여 경력 성장을 가속할 수 있습니다.

1 100% 합격률
2 2주간 덤프 연습
3 자격증 시험 합격
3
참고 답변
DevOps is a set of practices that combines software development (Dev) and IT operations (Ops) to shorten the development lifecycle and provide continuous delivery.
4
참고 답변
The Sidecar Pattern is a container-based design pattern where an auxiliary container (the "sidecar") is deployed alongside the main application container within the same deployment unit (e.g., a Kubernetes Pod). The sidecar container enhances or extends the functionality of the main application container by providing supporting features, and they share resources like networking and storage. **Key Characteristics:** 1. **Co-location:** The main application container and the sidecar container(s) run together in the same Pod (in Kubernetes) or task definition (in ECS). 2. **Shared Lifecycle:** Sidecars are typically started and stopped with the main application container. 3. **Shared Resources:** They share the same network namespace (can communicate via `localhost`) and can share volumes for data exchange. 4. **Encapsulation & Separation of Concerns:** The sidecar encapsulates common functionalities (like logging, monitoring, proxying) that would otherwise need to be built into each application or run as separate agents on the host. 5. **Language Agnostic:** Sidecars can be written in different languages than the main application, allowing teams to use the best tool for the job for auxiliary tasks. **Common Use Cases for Sidecars:** * **Log Aggregation:** A sidecar (e.g., Fluentd, Fluent Bit) collects logs from the main application container (e.g., from stdout/stderr or a shared volume) and forwards them to a centralized logging system. * **Metrics Collection:** A sidecar exports metrics from the application (e.g., Prometheus exporter) or provides a metrics endpoint. * **Service Mesh Proxy:** In a service mesh (e.g., Istio, Linkerd), a sidecar proxy (e.g., Envoy) runs alongside each application instance to manage network traffic, enforce policies, provide security (mTLS), and collect telemetry. * **Configuration Management:** A sidecar can fetch configuration updates from a central store and make them available to the main application, or reload the application when configuration changes. * **Secrets Management:** A sidecar can fetch secrets from a vault and inject them into the application environment or a shared volume. * **Network Utilities:** Providing network-related functions like SSL/TLS termination, circuit breaking, or acting as a reverse proxy. * **File Synchronization:** Syncing files from a remote source (like Git or S3) to a shared volume for the application to use. **Benefits:** * **Modularity and Reusability:** Common functionalities can be developed and deployed as separate sidecar containers, reusable across multiple applications. * **Reduced Application Complexity:** Keeps the main application focused on its core business logic. * **Independent Upgrades:** Sidecar functionalities can be updated independently of the main application. * **Polyglot Environments:** Allows auxiliary functions to be written in different languages/technologies. * **Encapsulation:** Isolates auxiliary tasks from the main application. **Considerations:** * **Resource Overhead:** Each sidecar consumes additional resources (CPU, memory). * **Increased Complexity (Deployment Unit):** While simplifying the application, it makes the deployment unit (Pod) more complex with multiple containers. * **Inter-Process Communication:** Communication between the app and sidecar (though often via localhost or shared volumes) needs to be efficient.
5
참고 답변
A Service Level Objective (SLO) is a specific, measurable, and achievable internal target for a particular aspect of service performance or reliability. SLOs are a key component of Site Reliability Engineering (SRE) practices and are used to guide engineering decisions and balance reliability work with feature development. **Key Characteristics of an SLO:** 1. **Service-Specific:** Defined for a particular user-facing service or critical internal system. 2. **User-Focused:** Based on what matters to users (e.g., availability, latency, correctness). 3. **Measurable:** Quantifiable using specific metrics (SLIs). 4. **Target Value:** A specific numerical goal (e.g., 99.9% availability, 99th percentile latency < 200ms). 5. **Measurement Window:** The period over which the SLO is evaluated (e.g., rolling 28 days, calendar month). 6. **Internal Target:** Used by the team providing the service to manage and improve reliability. SLOs are typically stricter than any corresponding SLAs to provide a safety margin. **Purpose of SLOs:** * **Data-Driven Decisions:** Provide a quantitative basis for making decisions about reliability, such as when to invest in more resilient infrastructure or when to prioritize bug fixes over new features. * **Error Budgets:** SLOs directly define error budgets. An error budget is the amount of time or number of events a service can fail to meet its SLO without breaching it. For example, an SLO of 99.9% availability over 30 days allows for approximately 43 minutes of downtime (the error budget). * **Balancing Reliability and Innovation:** If the service is consistently meeting its SLOs (i.e., not consuming its error budget), the team can focus more on feature development. If the error budget is being consumed rapidly, the team must prioritize reliability work. * **Shared Understanding:** Creates a common language and understanding of reliability goals across development, operations, and product teams. * **Alerting:** SLO burn rates (how quickly the error budget is being consumed) are often used to trigger alerts, prompting action before the SLO is breached. **How to Define Good SLOs:** 1. **Identify Critical User Journeys (CUJs):** What are the most important things users do with the service? 2. **Choose Appropriate SLIs:** Select metrics that accurately reflect the user experience for those CUJs (e.g., request success rate, latency at a specific percentile). 3. **Set Achievable Targets:** Consider historical performance, user expectations, and business requirements. Don't aim for 100% if it's not necessary or feasible, as it can be prohibitively expensive and stifle innovation. 4. **Document and Communicate:** Ensure SLOs are well-documented and understood by all stakeholders. 5. **Iterate:** Regularly review and refine SLOs based on new data and changing requirements. **Example SLO:** * **Service:** User Login API * **SLI:** Percentage of successful login requests (HTTP 200 responses) over all valid login attempts. * **Target:** 99.95% * **Period:** Measured over a rolling 28-day window. * **Consequence (Internal):** If the error budget (0.05%) is exceeded, new feature development for the login service is paused, and all engineering effort is directed towards reliability improvements until the service is back within SLO.
6
참고 답변
The technical know-how of a cloud engineer, the perceptions of a financial expert, and the clarity of project stakeholders can all be helpful to even the most seasoned FinOps practitioner. This type of conversation aims to discuss collaboration and examine how a candidate establishes a FinOps team and collaborates with others to build a valuable FinOps team. Without a team, there won't be buy-in, and FinOps won't function very effectively.
7
참고 답변
StatefulSets are used to manage stateful applications, providing guarantees about the ordering and uniqueness of Pods. Key features: Stable Network Identity: - Predictable Pod names - Stable hostnames Ordered Deployment: - Sequential creation - Sequential scaling - Sequential deletion Example of StatefulSet: apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: serviceName: "nginx" replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] resources: requests: storage: 1Gi
8
참고 답변
Branching in Git is a way to create separate lines of development within a project. A branch is like a pointer to a specific commit in the Git history. By default, Git starts with a main branch (commonly called main or master ). When you create a new branch, you're making a copy of the project's history at that point. This allows you to work on new features, bug fixes, or experiments without affecting the main codebase. - Each branch is independent, so changes don't interfere with others until merged. - Branches make parallel development possible (e.g., multiple developers working on different features). - You can easily merge branches to combine work or delete branches after completion. - Common branching strategies include Feature Branching, Git Flow, and Trunk-Based Development. Example: main branch → stable production code.feature/login branch → new login feature under development.- After testing, feature/login is merged back intomain .
9
참고 답변
I balance innovation and cost governance by embedding policies that are flexible but enforceable, using automation and governance to prevent waste without stifling experimentation. This includes setting review dates for policies and running small experiments to measure impact before scaling.
10
참고 답변
A variable spending model is a cost structure where expenses fluctuate based on usage, such as pay-as-you-go cloud services. Unlike fixed costs (e.g., upfront hardware purchases), variable costs scale with demand, allowing companies to pay only for resources consumed, which improves cost efficiency but requires careful monitoring to avoid overspending.
11
참고 답변
To ensure security and compliance in a CI/CD pipeline with multiple cloud providers and third-party services, implement robust authentication and authorization mechanisms. Utilize encryption for data in transit and at rest, and regularly audit access controls. Employ automated security scanning and testing throughout the pipeline to catch vulnerabilities early. Lastly, maintain clear documentation and communication channels to stay abreast of evolving compliance requirements.
12
참고 답변
DevOps is a set of practices that brings together development and operations teams to streamline software delivery. The goal? Faster releases, higher quality, and tighter feedback loops. In practice, this means reducing the conflict between code writing and code running. It's not just about tools, but about culture, automation, and ownership. In my previous role, we adopted DevOps to accelerate the deployment of our ML models, which could drastically reduce our deployment time while also improving stability.
13
참고 답변
Infrastructure as Code (IaC) is the practice of managing and provisioning computing infrastructure through machine-readable definition files, rather than physical hardware configuration. Its benefits include faster deployment, consistency, scalability, and easier management. Challenges may include initial learning curve, complexity in maintaining code, and ensuring security and compliance across diverse environments.
14
참고 답변
A tool for analyzing, forecasting, and optimizing Azure spend.
15
참고 답변
- Jenkins uses an internal database to store user data and credentials. - Jenkins can use the Lightweight Directory Access Protocol (LDAP) server to authenticate users. - Jenkins can be configured to employ the authentication mechanism that the deployed application server uses.
16
참고 답변
FinOps professionals come from a variety of different backgrounds and areas of expertise. For example, I studied Industrial Engineering in school. With this background, I learned about the practice of building processes and adapting them as conditions change. I also work as an intermediary/"translator" between management and technical roles and have learned how to communicate between these two (often opposing) teams. In this role, I embraced processes and standards and developed new approaches to improve existing processes. This served me well as I eventually broke into FinOps — which is all about applying a financial way of thinking to the cloud, building financial processes , serving as a go-between for both financial and technical teams, and providing financial oversight to cloud stakeholders. In my experience, more FinOps professionals come from a technical background as it is easier for a technical person to learn finance than the other way around.
17
참고 답변
Amazon Web Services (AWS) is a comprehensive, evolving cloud computing platform provided by Amazon.
18
참고 답변
Amazon Elastic Compute Cloud (EC2) provides resizable compute capacity in the cloud.
19
참고 답변
Using encryption, access controls, and regular audits.
20
참고 답변
- Analyze cost by service - Identify anomalies - Check scaling & deployments - Review tagging - Implement immediate controls
21
참고 답변
Branching is a method that is used to separate JavaScript. Put it allows a clone of the source system to build two independently created copies. There are different forms of branching. Based on the domain specifications, the DevOps team should then make a decision. This alternative is called strategic branching.
22
참고 답변
When I receive an alert—usually through PagerDuty—my first step is assessing the scope and impact. For a recent database connectivity issue, I quickly checked our status page and internal Slack to see if others were reporting problems. I followed our runbook to restart the connection pool, which resolved the immediate issue in about 5 minutes. But the important part came after: I conducted a post-mortem meeting where we discovered the root cause was a memory leak in our application. We implemented additional monitoring and updated our deployment process to catch similar issues in testing.
23
참고 답변
Auto-scaling is a cloud computing feature that automatically adjusts the number of active servers to match the current load.
24
참고 답변
Sanity testing, also known as smoke testing, is a process used to determine if it's reasonable to proceed to test. Git repository provides a hook called pre-commit which gets triggered right before a commit happens. A simple script by making use of this hook can be written to achieve the smoke test. The script can be used to run other tools like linters and perform sanity checks on the changes that would be committed into the repository. The following snippet is an example of one such script: #!/bin/sh files=$(git diff –cached –name-only –diff-filter=ACM | grep ‘.py$') if [ -z files ]; then exit 0 fi unfmtd=$(pyfmt -l $files) if [ -z unfmtd ]; then exit 0 fi echo “Some .py files are not properly fmt'd” exit 1 The above script checks if any .py files which are to be committed are properly formatted by making use of the python formatting tool pyfmt. If the files are not properly formatted, then the script prevents the changes to be committed to the repository by exiting with status 1.
25
참고 답변
Governance ensures cost control without slowing innovation. Techniques: - Budgets & alerts - Spend limits - Policy-as-code - Approval workflows for large resources
26
참고 답변
Tags enable cost allocation, chargeback, and accountability. Best Practices: - Mandatory tags (Owner, Environment, CostCenter) - Enforce via policy - Automate tagging in IaC
27
참고 답변
A Web Application Firewall (WAF) is a security device that monitors incoming traffic to a web application and blocks malicious traffic. Key features: 1. **Filtering:** - Filters out malicious traffic - Allows legitimate traffic 2. **Authentication:** - Verifies the identity of the communicating parties Example of WAF configuration: security: waf: enabled: true rules: - rule1 - rule2
28
참고 답변
HTTP requests (methods) play a crucial role in DevOps when interacting with APIs, automation, webhooks, and monitoring systems. Here are the main HTTP methods used in a DevOps context: GET: Retrieves information or resources from a server. Commonly used to fetch data or obtain status details in monitoring systems or APIs. POST: Submits data to a server to create a new resource or initiate an action. Often used in APIs to create new items, trigger builds, or start deployments. PUT: Updates a resource or data on the server. Used in APIs and automation to edit existing information or re-configure existing resources. PATCH: Applies partial updates to a resource on the server. Utilized when only a certain part of the data needs an update, rather than the entire resource. DELETE: Deletes a specific resource from the server. Use this method to remove data, stop running processes, or delete existing resources within automation and APIs. HEAD: Identical to GET but only retrieves the headers and not the body of the response. Useful for checking if a resource exists or obtaining metadata without actually transferring the resource data. OPTIONS: Retrieves the communication options available for a specific resource or URL. Use this method to identify the allowed HTTP methods for a resource, or to test the communication capabilities of an API. CONNECT: Establishes a network connection between the client and a specified resource for use with a network proxy. TRACE: Retrieves a diagnostic representation of the request and response messages for a resource. It is mainly used for testing and debugging purposes.
29
참고 답변
The following are the cloud platforms that Docker runs on: - Amazon Web Services - Microsoft Azure - Google Cloud Platform - Rackspace
30
참고 답변
Post Mortem meetings are those that are arranged to discuss if certain things go wrong while implementing the DevOps methodology. When this meeting is conducted, it is expected that the team has to arrive at steps that need to be taken in order to avoid the failure(s) in the future.
31
참고 답변
Developers are obliged to commit all source code changes to a shared DevOps repository. Every time a change is made in the code, Jenkins-like Continuous Integration tools will grab it from this common repository and deploy it for Continuous Testing, which is done by tools like Selenium.
32
참고 답변
The following table enables you to understand the main difference between Continuous Deployment and Continuous Delivery | Feature | Continuous Delivery | Continuous Deployment | |---|---|---| | What it is | Code is ready to go live anytime, but someone must click "deploy" | Code goes live automatically once it passes all tests | | Automation Level | Most steps are automatic, except the final release | Everything is fully automatic, including release | | Who starts deployment? | A human decides when to release | The system does it automatically after testing | | Control | You control when changes go live | Less control: changes go live as soon as they pass tests | | Safety | Safer: you can review before going live | Riskier: must rely on great testing | | Speed | Slower feedback because of manual step | Fast feedback: users see updates right away | | Best for | Teams needing control or working in regulated environments | Teams pushing updates often, like websites or online tools | | Example Company | Facebook: they manually control when updates go live | Etsy: they release code to users multiple times a day | | Hard Part | Setting up the process and still needing humans to release | Requires really good automated testing and monitoring | | Setup Difficulty | Medium: mix of automation and manual steps | Hard: needs full automation and constant monitoring |
33
참고 답변
Docker is a tool designed to make it easier to create, deploy, and run applications by using containers.
34
참고 답변
Classes are named blocks in your manifest that configure various functionalities of the node, such as services, files, and packages. The classes are added to a node's catalog and are executed only when explicitly invoked. Class apache (String $version = ‘latest') { package{ ‘httpd': ensure => $version, before => File[‘/etc/httpd.conf'],}
35
참고 답변
A thorough understanding of a particular cloud provider can be necessary for workload designs, deployments, optimizations, and cost management. For instance, a company using AWS will be interested in learning about a candidate's familiarity with the resources, services, and pricing associated with that cloud. If the firm wants to build up FinOps fast, having this understanding might give you an edge over other applicants.
36
참고 답변
A service mesh is a dedicated infrastructure layer for handling service-to-service communication in microservices architectures. Key components: Data Plane: - Service proxies (sidecars) - Traffic handling - Security enforcement Control Plane: - Configuration management - Policy enforcement - Service discovery Example of Istio configuration: apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews-route spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 weight: 75 - destination: host: reviews subset: v2 weight: 25
37
참고 답변
Tracing is the process of tracking the flow of requests through a distributed system, helping to identify bottlenecks and performance issues. Tools like Jaeger and Zipkin are commonly used.
38
참고 답변
Policy as Code (PaC) is the practice of defining, managing, and automating policies using code and version control systems, similar to Infrastructure as Code (IaC). Instead of manually configuring policies through UIs or disparate systems, PaC allows organizations to express policies in a high-level, human-readable language, store them in a Git repository, and apply them automatically throughout the development lifecycle and in production environments. **Key Concepts:** 1. **Policy Definition:** Policies are written in a declarative language (e.g., Rego for Open Policy Agent, Sentinel for HashiCorp tools). 2. **Version Control:** Policies are stored in Git, enabling versioning, auditing, and collaboration. 3. **Automation:** Policies are automatically enforced at various stages (e.g., CI/CD pipeline, infrastructure provisioning, Kubernetes admission control). 4. **Shift Left:** Enables early detection and prevention of policy violations during development. 5. **Auditability:** Provides a clear audit trail of policy changes and enforcement. **Use Cases:** * **Security:** Enforcing security best practices, such as disallowing public S3 buckets or ensuring encryption. * **Compliance:** Meeting regulatory requirements (e.g., GDPR, HIPAA) by codifying compliance rules. * **Cost Management:** Preventing the creation of overly expensive resources. * **Operational Consistency:** Ensuring standardized configurations across environments. * **Kubernetes Governance:** Controlling what can be deployed to a Kubernetes cluster (e.g., required labels, resource limits, image sources). **Popular Tools:** * **Open Policy Agent (OPA):** An open-source, general-purpose policy engine. * **HashiCorp Sentinel:** A policy as code framework embedded in HashiCorp enterprise products (Terraform, Vault, Nomad, Consul). * **Kyverno:** A policy engine designed specifically for Kubernetes. * Cloud provider specific tools (e.g., AWS Config Rules, Azure Policy). **Example (Conceptual OPA/Rego):** package main # Deny deployments if an image is not from a trusted registry deny[msg] { input.kind == "Deployment" image_name := input.spec.template.spec.containers[_].image not startswith(image_name, "trusted.registry.io/") msg := sprintf("Image '%v' is not from a trusted registry", [image_name]) }
39
참고 답변
I follow the principle of least privilege religiously. In AWS, I use IAM roles instead of users whenever possible and regularly audit permissions with Access Analyzer. I've implemented automated security scanning with tools like Prowler that runs daily and alerts on misconfigurations. For network security, all our resources are in private subnets with NACLs and security groups configured to allow only necessary traffic. I also ensure encryption at rest and in transit—for example, our RDS instances use KMS encryption and all API calls go through TLS.
40
참고 답변
Amazon Athena is a serverless query service that allows users to analyze data in Amazon S3 using standard SQL. Behind the scenes, it uses Presto, a distributed SQL query engine, to scan data directly from S3, requiring no data loading or infrastructure management. It leverages AWS Glue for schema discovery and cataloging, enabling querying of both structured and unstructured data.
41
참고 답변
The various aspects of the DevOps lifecycle are as the following: - Plan– Originally, a schedule should be drawn up for the form of application to be created. It is still a smart thing to get a clear view of the production process. - Code-The program is configured according to the needs of the end-user. - Construct– Build the program by combining different codes developed in the preceding phases. - Test-This is the most critical step in the creation of an application. Check the document, and if necessary, restore it. - Integrate– Several codes are built into one by various programmers. - Deploy– Technology is being distributed for further use in a cloud environment. It is assumed that the new developments will not impact the operation of a website with heavy traffic. - Operate– Where necessary, operations are conducted on the file. - Monitor– It tracks the performance of programs. Changes are made to meet the demands of the end-user.
42
참고 답변
By using tools like Flyway or Liquibase, which track, manage, and apply database schema changes and migrations, ensuring consistency across environments.
43
참고 답변
The correct answer is B) git mv
44
참고 답변
A hypervisor is a layer of software that enables virtualization by allowing multiple virtual machines to share a single physical server or computer. It manages the allocation of hardware resources to each virtual machine and isolates each virtual machine from the others.
45
참고 답변
To build a Docker compose, a user can use a JSON file instead of YAML. In case a user wants to use a JSON file, he/she should specify the filename as given: Docker-compose -f Docker-compose.json up
46
참고 답변
Deployment Strategies are methods used to deploy applications to Kubernetes clusters. Common strategies include: Blue-Green Deployment: - Deploy a new version of the application - Traffic is routed to the new version - Old version is kept running Canary Deployment: - Deploy a new version of the application - Traffic is routed to the new version - Old version is kept running Rolling Update: - Deploy a new version of the application - Old version is gradually replaced - Traffic is routed to the new version Blue-Green with Rolling Update: - Deploy a new version of the application - Traffic is routed to the new version - Old version is gradually replaced
47
참고 답변
It is also referred to as cache stampede which can occur when huge parallel computing systems employing caching strategies are subjected to very high load. It is referred to as that event that occurs when the cache expires (or invalidated) and multiple requests are hit to the website at the same time. The most common way of preventing dogpiling is by implementing semaphore locks in the cache. When the cache expires in this system, the first process to acquire the lock would generate the new value to the cache.
48
참고 답변
A Service Catalog is a centralized, curated list of IT services that an organization offers to its employees or customers. In the context of DevOps and Platform Engineering, it's a key component of an Internal Developer Platform (IDP), providing developers with a self-service portal to discover, request, and provision standardized resources, tools, and environments. **Key Characteristics & Purpose:** 1. **Discoverability:** Provides a single place for users (typically developers) to find available services (e.g., databases, CI/CD pipeline templates, Kubernetes clusters, monitoring dashboards). 2. **Standardization:** Offers pre-configured, vetted, and compliant versions of services, ensuring consistency and adherence to organizational best practices. 3. **Self-Service:** Enables users to request and provision services on-demand without manual intervention from IT operations or platform teams. 4. **Automation:** Behind the scenes, service requests from the catalog trigger automated provisioning workflows. 5. **Lifecycle Management:** Can include information about service versions, support, and decommissioning. 6. **Transparency:** Often includes details about service SLAs, costs, and usage guidelines. **Benefits:** * **Increased Developer Productivity:** Developers can quickly access the resources they need without waiting for manual fulfillment. * **Improved Governance & Compliance:** Ensures that only approved and compliant services are used. * **Reduced Operational Overhead:** Automates service provisioning, freeing up operations teams. * **Enhanced Consistency:** Standardized services reduce configuration drift and compatibility issues. * **Cost Control:** Can provide visibility into service costs and help manage cloud spend by offering optimized options. * **Better User Experience:** Simplifies the process of obtaining IT resources. **Examples of Services in a Developer-Focused Service Catalog:** * New Microservice Template (with CI/CD pipeline) * Managed PostgreSQL Database (various sizes) * Kubernetes Namespace with pre-defined quotas * On-demand Test Environment * Access to a specific logging or monitoring tool * Vulnerability Scanning Service **Tools:** * **Backstage (CNCF):** An open platform for building developer portals, often used to create service catalogs. * **Port:** A developer portal platform. * IT Service Management (ITSM) tools (e.g., ServiceNow, Jira Service Management) can also be adapted. * Custom-built portals.
49
참고 답변
Common cloud migration strategies (6 R's): 1. **Rehosting (Lift and Shift):** - Moving applications without changes - Quickest migration method - Minimal optimization 2. **Replatforming (Lift, Tinker and Shift):** - Minor optimizations - Cloud-specific improvements - Maintaining core architecture 3. **Refactoring/Re-architecting:** Benefits: - Better cloud-native features - Improved scalability - Enhanced performance Challenges: - More time-consuming - Higher initial costs - Required expertise
50
참고 답변
Service Level Indicators (SLIs) are quantitative measures of service level aspects such as latency, throughput, availability, and error rate. Common SLIs: Request Latency: - Time to handle a request - Distribution of response times Error Rate: - Failed requests/total requests - Error budget consumption System Throughput: - Requests per second - Transactions per second
51
참고 답변
A Service Level Indicator (SLI) is a quantitative measure of some aspect of the level of service provided to users. SLIs are the raw data points or metrics used to assess performance against Service Level Objectives (SLOs). They are crucial for objectively understanding how a service is performing from a user's perspective. **Key Characteristics of an SLI:** 1. **Quantitative Measure:** A specific, numerical value derived from system telemetry. 2. **User-Centric:** Reflects an aspect of service performance that directly impacts user experience. 3. **Directly Measurable:** Can be obtained from monitoring systems, logs, or other data sources. 4. **Good Proxy for User Happiness:** A change in the SLI should correlate with a change in user satisfaction. 5. **Reliably Measured:** The measurement itself should be accurate and dependable. **Common Types of SLIs:** * **Availability:** Measures the proportion of time the service is usable or the percentage of successful requests. * *Example:* (Number of successful HTTP requests / Total valid HTTP requests) * 100%. * **Latency:** Measures the time taken to serve a request. Often measured at specific percentiles (e.g., 95th, 99th percentile) to understand typical and worst-case performance. * *Example:* The 99th percentile of API response times for the `/users` endpoint over the last 5 minutes. * **Error Rate:** Measures the proportion of requests that result in errors. * *Example:* (Number of HTTP 5xx responses / Total valid HTTP requests) * 100%. * **Throughput:** Measures the rate at which the system processes requests or data. * *Example:* Requests per second (RPS) handled by the shopping cart service. * **Durability:** Measures the likelihood that data stored in the system will be retained over a long period without corruption. * *Example:* Probability of a stored object remaining intact and accessible after one year. * **Correctness/Quality:** Measures if the service provides the right answer or performs the right action. * *Example:* Percentage of search queries that return relevant results, or proportion of financial transactions processed without data errors. **How to Choose Good SLIs:** 1. **Focus on User Experience:** What aspects of performance or reliability are most important to your users? 2. **Keep it Simple:** Choose a small number of meaningful SLIs rather than trying to track everything. 3. **Ensure it's Actionable:** The SLI should provide data that can lead to improvements or inform decisions. 4. **Distinguish from Raw Metrics:** While SLIs are derived from metrics, they are specifically chosen and often processed (e.g., aggregated, percentiled) to represent service level. **Relationship with SLOs and SLAs:** * SLIs are the **measurements**. * SLOs are the **targets** for those measurements (e.g., SLI for availability >= 99.9%). * SLAs are the **agreements** with users, often based on achieving certain SLOs, and typically include consequences if not met. **Example:** * **User Journey:** User uploads a photo. * **Possible SLIs:** * `upload_success_rate`: (Number of successful photo uploads / Total photo upload attempts) * 100% * `upload_latency_p95`: 95th percentile of time taken from initiating upload to confirmation. * **Corresponding SLO for `upload_success_rate` might be:** 99.9% over a 7-day window.
52
참고 답변
The main configuration file consists of several directives that affect how Nagios operates. The Nagios process and the CGIs read the config file. A sample main configuration file will be placed into your settings directory: /usr/local/Nagios/etc/resource.cfg
53
참고 답변
Showback builds cost visibility and educates teams by displaying cloud spend without charging, while chargeback enforces accountability by directly billing teams for their cloud usage.
54
참고 답변
Get command is used to retrieve the text of a specified web element. The command does not return any parameter but returns a string value. Used for: - Verification of messages - Labels - Errors displayed on the web page Syntax: String Text=driver.findElement(By.id(“text”)).getText();
55
참고 답변
Reserved Instances (RIs) provide a significant discount compared to On-Demand pricing in exchange for a commitment to use a specific instance configuration for a one or three-year term. Types of RIs: Standard RIs: - Highest discount (up to 75%) - Least flexibility - Best for steady-state workloads Convertible RIs: - Lower discount (up to 54%) - More flexibility - Can change instance family, OS, tenancy Scheduled RIs: - For predictable recurring schedules - Match capacity reservation to usage pattern
56
참고 답변
Every domain has its pitfalls. What does your candidate identify as the most common mistakes in cloud cost management? More importantly, how do they propose to avoid them? Their insights can help you prevent avoidable setbacks in your cloud cost strategies.
57
참고 답변
Here are the best practices for applying DevOps are essential: - Delivery pace means the time required to get them into the manufacturing process for any job. - Track how many faults are contained in the different - In case of a malfunction in the manufacturing process, it is necessary to calculate the real or the average time it takes to recover. - The number of errors the user is discovering often impacts the application's consistency.
58
참고 답변
API Security involves protecting APIs from threats and vulnerabilities while ensuring they remain accessible to authorized users. Key security measures: Authentication: - API keys - OAuth 2.0 - JWT tokens Authorization: - Role-based access control - Scope-based access - Resource-level permissions Example of OAuth2 configuration: security: oauth2: client: clientId: ${CLIENT_ID} clientSecret: ${CLIENT_SECRET} resource: tokenInfoUri: https://api.auth.com/oauth/check_token
59
참고 답변
I use tools like Terraform and Ansible. They allow infrastructure setup and configuration to be defined in code formats, ensuring consistent and reproducible infrastructure provisioning.
60
참고 답변
- Move the job from one Jenkins installation to another by copying the corresponding job directory. - Create a copy of an existing job by making a clone of a job directory with a different name. - Rename an existing job by renaming a directory.
61
참고 답변
Monitoring and logging are two different practices in DevOps: Monitoring: - Focuses on collecting and analyzing data about the performance and stability of services and infrastructure to improve the system's reliability. - Key aspects include: - Infrastructure Monitoring - Application Monitoring - User Experience Monitoring Logging: - Focuses on collecting and analyzing log data to help diagnose and troubleshoot issues. - Key aspects include: - Log aggregation - Security analytics - Application performance monitoring - Website search - Business analytics
62
참고 답변
Infrastructure Security involves securing all infrastructure components including: Network Security: - Firewalls - VPNs - Network segmentation - DDoS protection Cloud Security: - Identity and Access Management (IAM) - Encryption - Security groups - Network ACLs Host Security: - OS hardening - Patch management - Antivirus - Host-based firewalls
63
참고 답변
Sudo (Super User DO) command in Linux is generally used as a prefix for some commands that only superusers are allowed to run. If you prefix any command with “sudo”, it will run that command with elevated privileges or in other words allow a user with proper permissions to execute a command as another user, such as the superuser. This is the equivalent of the “run as administrator” option in Windows.
64
참고 답변
A Pod is a mapping between containers in Kubernetes. A Pod may contain multiple containers. Pods have a flat network hierarchy inside an overlay network and communicate to each other in a flat fashion, meaning that in theory any pod inside that overlay network can speak to any other Pod.
65
참고 답변
Automation plays a critical role in DevOps, allowing teams to develop, test, and deploy software more efficiently by reducing manual intervention, increasing consistency, and accelerating processes. Key aspects of automation in DevOps include Continuous Integration (CI), Continuous Deployment (CD), Infrastructure as Code (IaC), Configuration Management, Automated Testing, Monitoring and Logging, Automated Security, among others. By automating these aspects of the software development lifecycle, DevOps teams can streamline their workflows, maximize efficiency, reduce errors, and ultimately deliver higher-quality software faster.
66
참고 답변
The biggest mistake I've made since working in FinOps was not fully understanding my business environment. In a specific example, I was unaware that a particular business unit was going to increase its cloud spend by 160% in a single month. When the bill arrived, it was a huge surprise for all–and not in a good way. In retrospect, I think we could have built a better relationship with this particular business owner. This way, I could have understood his plans, and ensured he understood the financial impact. Additionally, we could have looked for a solution that optimized the cost.
67
참고 답변
- Writing code to manage configuration, deployment, and automatic provisioning. - Managing data centers with machine-readable definition files, rather than physical hardware configuration. - Ensuring all your servers and other infrastructure components are provisioned consistently and effortlessly. - Administering cloud computing environments, also known as infrastructure as a service (IaaS).
68
참고 답변
A firewall in cloud computing is a security system that monitors and controls incoming and outgoing network traffic based on predetermined security rules.
69
참고 답변
I track metrics such as cost per unit (e.g., per transaction or user), cloud spend vs. budget variance, savings achieved from optimizations, anomaly detection response time, and mean time to savings (MTTS). Additionally, I monitor utilization rates of RIs/Savings Plans and team cost accountability scores via showback/chargeback.
70
참고 답변
- chef-apply is run on the client system. chef-apply applies the recipe mentioned in the command on the client system. $ chef-apply recipe_name.rb - chef-client is also run on the client system. chef-client applies all the cookbooks in your server's run list to the client system. $ knife chef-client
71
참고 답변
GitHub Actions is a CI/CD and automation platform built into GitHub that allows you to automate workflows for building, testing, and deploying code directly from your repository.
72
참고 답변
The most popular DevOps tools include:
73
참고 답변
Monitoring and logging are two different practices in DevOps: Monitoring: - Focuses on collecting and analyzing data about the performance and stability of services and infrastructure to improve the system's reliability. - Key aspects include: - Infrastructure Monitoring - Application Monitoring - User Experience Monitoring Logging: - Focuses on collecting and analyzing log data to help diagnose and troubleshoot issues. - Key aspects include: - Log aggregation - Security analytics - Application performance monitoring - Website search - Business analytics
74
참고 답변
Continuous integration is an increasingly critical aspect of the Agile process. Developers usually function during a sprint on functionality or user experiences and contribute their version control repository changes. If the code has been committed, then the developers' entire work is well organized, and the build is done on a routine basis depending on each check-in or schedule. Continuous integration thus requires the creator to merge their improvements with the others, to receive early feedback.
75
참고 답변
Priority goes to restoring service. After that, I identify the root cause and implement preventive measures. Communication with stakeholders throughout is crucial.
76
참고 답변
Infrastructure Security involves securing all infrastructure components including: Network Security: - Firewalls - VPNs - Network segmentation - DDoS protection Cloud Security: - Identity and Access Management (IAM) - Encryption - Security groups - Network ACLs Host Security: - OS hardening - Patch management - Antivirus - Host-based firewalls
77
참고 답변
Use the `mv` command in the console to rename a file. For example: `mv oldname.txt newname.txt`.
78
참고 답변
Implementing regular backups, multi-region deployment, and having a documented and tested disaster recovery plan in place.
79
참고 답변
To ensure high availability, I implement redundancy and failover mechanisms across all critical components. I also use advanced monitoring and alerting systems to detect and address issues proactively, ensuring minimal downtime.
80
참고 답변
The DevOps lifecycle includes the following phases: - Planning: Defining project requirements and scope. - Development: Writing and testing code. - Integration: Merging code changes into a shared repository. - Testing: Automated testing to ensure code quality. - Deployment: Releasing the code to production. - Monitoring: Continuous monitoring and logging to ensure system health. - Feedback: Collecting and analyzing user feedback for improvements.
81
참고 답변
Tools and software can make or break efficiency. Ask them about their favorites and why they use them. Are they fans of AWS Cost Explorer, Azure Cost Management, or Google Cloud's offerings? These tools can provide insights into their workflow and efficiency.
82
참고 답변
Savings Plans provide discounted rates in exchange for a 1 or 3-year compute commitment, automatically applied across EC2, Fargate, and Lambda.
83
참고 답변
Using Infrastructure as Code enhances collaboration by enabling version control of infrastructure changes, fostering code review practices, supporting modular reusable code, providing consistency across environments, and allowing teams to work in parallel with reduced risks of configuration drift.
84
참고 답변
An Incident Response Playbook is a specialized type of runbook focused specifically on guiding the actions of a response team during and after a security incident or significant operational outage. It provides a predefined and structured set of steps to detect, analyze, contain, eradicate, and recover from specific types of incidents. **Key Differences from General Runbooks:** * **Focus:** Primarily on security incidents (e.g., data breach, malware infection, DDoS attack) or major service outages, whereas runbooks can cover routine operational tasks as well. * **Goal:** To minimize the impact of an incident, restore service quickly and securely, and gather information for post-incident analysis and learning. * **Audience:** Often used by security teams (CSIRT - Computer Security Incident Response Team), SREs, and operations staff involved in incident handling. **Core Components of an Incident Response Playbook:** 1. **Incident Type:** Clearly defines the specific incident the playbook addresses (e.g., "Phishing Attack Leading to Credential Compromise," "Ransomware Outbreak," "Database Unavailability"). 2. **Roles and Responsibilities:** Identifies who is responsible for each action (e.g., Incident Commander, Communications Lead, Technical Lead). 3. **Preparation/Prerequisites:** Steps taken before an incident occurs (e.g., ensuring logging is enabled, access to necessary tools). 4. **Detection and Identification:** How to recognize that this specific type of incident is occurring (e.g., specific alerts, user reports, anomalous behavior). 5. **Containment Strategy:** Steps to limit the scope and impact of the incident (e.g., isolating affected systems, blocking malicious IPs, disabling compromised accounts). 6. **Eradication:** How to remove the cause of the incident (e.g., removing malware, patching vulnerabilities). 7. **Recovery:** Steps to restore affected systems and services to normal operation safely. 8. **Post-Incident Activities (Postmortem):** Procedures for analyzing the incident, documenting lessons learned, and improving defenses and response capabilities. This includes evidence preservation. 9. **Communication Plan:** Guidelines for internal and external communication (e.g., notifying stakeholders, legal, PR, customers if necessary). 10. **Checklists and Decision Trees:** To guide responders through complex scenarios. 11. **Tools and Resources:** List of necessary tools, contact information, and knowledge base articles. **Benefits of Incident Response Playbooks:** * **Faster Response Times:** Enables quicker, more decisive action during high-stress situations. * **Consistency:** Ensures a standardized approach to incident handling, regardless of who is responding. * **Reduced Human Error:** Minimizes mistakes made under pressure. * **Improved Decision Making:** Provides a framework for making critical decisions. * **Compliance and Legal Adherence:** Helps meet regulatory requirements for incident response. * **Effective Training Tool:** Can be used for drills and exercises to prepare teams. * **Continuous Improvement:** Forms the basis for learning from incidents and refining response strategies. **Example Playbook Scenario: DDoS Attack Mitigation** * **Detection:** Monitoring alerts for unusually high traffic volumes, high server load, and service unavailability. * **Initial Triage:** Confirm it's a DDoS attack and not a legitimate traffic spike. Identify attack vectors (e.g., volumetric, protocol, application layer). * **Containment/Mitigation:** * Engage DDoS mitigation service (e.g., Cloudflare, AWS Shield). * Implement rate limiting and IP blocking at edge firewalls/load balancers. * Scale out backend resources if applicable. * **Recovery:** Monitor traffic and service health. Gradually remove mitigation measures once the attack subsides. * **Post-Incident:** Analyze attack patterns, identify vulnerabilities, update mitigation strategies, and document the incident.
85
참고 답변
Expose - Expose is an instruction used in Dockerfile. - It is used to expose ports within a Docker network. - It is a documenting instruction used at the time of building an image and running a container. - Expose is the command used in Docker. - Example: Expose 8080 Publish - Publish is used in a Docker run command. - It can be used outside a Docker environment. - It is used to map a host port to a running container port. - --publish or –p is the command used in Docker. - Example: docker run –d –p 0.0.0.80:80
86
참고 답변
Factors include total spend by service, account, and tag; cost trends; anomaly alerts; savings opportunities (RI/SP usage); and budget forecasts. Reporting is important for driving accountability, enabling data-driven decisions, and ensuring cost optimization aligns with business goals.
87
참고 답변
- Cluster autoscaling - Namespace-level quotas - Spot instances - Resource requests & limits - Cost visibility per workload Tools: - Kubecost - OpenCost - Prometheus
88
참고 답변
A DevOps engineer is a person who works with both software developers and the IT staff to ensure smooth code releases. They are generally developers who develop an interest in the deployment and operations domain or the system admins who develop a passion for coding to move towards the development side. In short, a DevOps engineer is someone who has an understanding of SDLC (Software Development Lifecycle) and of automation tools for developing CI/CD pipelines.
89
참고 답변
I automate reporting and allocation for showback/chargeback by using self-service dashboards (Power BI, Tableau, AWS Cost Explorer) for transparency and leveraging automation tools for consistent enforcement of cost policies.
90
참고 답변
Microservices is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain. Key characteristics: Independence: - Separate codebases - Independent deployment - Different technology stacks Communication: - API-based interaction - Event-driven - Service discovery Example of a microservice API: openapi: 3.0.0 info: title: User Service API version: 1.0.0 paths: /users: get: summary: List users responses: '200': description: List of users post: summary: Create user responses: '201': description: User created
91
참고 답변
Designing infrastructure automation for scalability and repeatability involves defining infrastructure as code, using tools like Terraform or CloudFormation, modularizing code bases, applying idempotent scripts, leveraging configuration management tools, and integrating automated testing and validation processes.
92
참고 답변
Continuous monitoring in DevOps is a process of detecting, identifying, and reporting faults or threats in the system's entire infrastructure. - Ensures that all services, applications, and resources are running on the servers properly. - Monitors the status of servers and determines if applications are working correctly or not. - Enables continuous audit, transaction inspection, and control monitoring.
93
참고 답변
The Chef client and the server use SSL certificates to ensure that each node has access to the appropriate data. -nodes have a combination of secret and public keys. The public key is kept in the folder Chef. When submitting an SSL certificate to the database, it will hold the node's secret key. The server contrasts this against the key to define the node and grant the node access to the necessary data.
94
참고 답변
A Self-Healing System is an architecture that can automatically detect and recover from failures, often using automation, monitoring, and orchestration tools to maintain availability.
95
참고 답변
I've built and maintained CI/CD pipelines using GitLab CI and AWS CodePipeline. Our current setup automatically runs tests, builds Docker images, and deploys to staging when developers merge code. For production deployments, we use blue-green deployments with manual approval gates. I've also implemented infrastructure pipelines that validate Terraform changes in a staging environment before applying to production. This approach caught several potential issues, including when a teammate accidentally tried to delete our production RDS instance.
96
참고 답변
By using redundant systems, load balancing, and failover mechanisms.
97
참고 답변
Helm is a package manager for Kubernetes that helps you manage Kubernetes applications through Helm Charts. Key concepts: Charts: - Package format - Collection of files - Template mechanism Repositories: - Chart storage - Version control - Distribution Example of Helm Chart: apiVersion: v2 name: my-app description: A Helm chart for my application version: 0.1.0 dependencies: - name: mysql version: 8.8.3 repository: https://charts.bitnami.com/bitnami
98
참고 답변
ELK Stack is a collection of three open-source products: - Elasticsearch: A search and analytics engine - Logstash: A server‑side data processing pipeline - Kibana: A visualization tool for Elasticsearch data Common use cases: - Log aggregation - Security analytics - Application performance monitoring - Website search - Business analytics
99
참고 답변
Chef | Puppet | |---|---| | Ruby programming knowledge is needed to handle the management of Chef. | DSL programming knowledge is needed to handle the management of Puppet. | | Chef is mostly used by small and medium-sized companies for management. | Large corporations and enterprises use Puppet for management. | | There is no error visibility at installation time which results in difficulty. | Error visibility at installation time is provided to ease the installation process. | | The transmission process to establish communication in this software is slower as compared to Puppet. | The transmission process to establish communication in this software is faster as compared to Chef. |
100
참고 답변
The answer should include methods like setting up budget alerts, using anomaly detection tools (e.g., AWS Anomaly Detection), monitoring cost and usage reports, and analyzing trends to identify unusual patterns.
101
참고 답변
Prometheus is an open-source systems monitoring and alerting toolkit. Key features include: - Time series database - Flexible query language (PromQL) - Pull-based metrics collection - Alert management - Visualization capabilities Example of Prometheus configuration: global: scrape_interval: 15s scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['localhost:9090'] - job_name: 'node' static_configs: - targets: ['localhost:9100']
102
참고 답변
Configuration Management is the process of maintaining systems, such as computer systems and servers, in a desired state. It's a way to make sure that a system performs as it's supposed to as changes are made over time. Key aspects include: - System configuration - Application configuration - Dependencies management - Version control - Compliance and security
103
참고 답변
Classic automation covers the automation of software installation and system configuration such as user creation, permissions, security baselining, while orchestration is more focused on the connection and interaction of existing and provided services. (Configuration management covers both classic automation and orchestration.) Most cloud providers have components for application servers, caching servers, block storage, message queueing databases etc. They can usually be configured for automated backups and logging. Because all these components are provided by the cloud provider it becomes a matter of orchestrating these components to create an infrastructure solution. The amount of classic automation necessary on cloud environments depends on the number of components available to be used. The more existing components there are the less classic automatic is necessary. In local or On-Premise environments you first have to automate the creation of these components before you can orchestrate them. For AWS a common solution is CloudFormation, with lots of different types of wrappers around it. Azure uses deployments and Google Cloud has the Google Deployment Manager. A common orchestration solution that is cloud-provider-agnostic is Terraform. While it is closely tied to each cloud, it provides a common state definition language that defines resources (like virtual machines, networks, and subnets) and data (which references existing state on the cloud.) Nowadays most configuration management tools also provide components to manage the orchestration solutions or APIs provided by the cloud providers.
104
참고 답변
Docker provides containerization, enabling consistent environments. I've used it to create, deploy, and run applications in isolated containers, ensuring they behave consistently across different stages.
105
참고 답변
MTTR is the average time it takes to recover from a system failure or incident. Calculation: MTTR = Total Recovery Time / Number of Incidents Components of MTTR: 1. **Detection Time:** - Time to identify the issue - Monitoring alerts 2. **Response Time:** - Time to begin addressing the issue - Team mobilization 3. **Resolution Time:** - Time to fix the issue - System restoration
106
참고 답변
Stackdriver is a monitoring, logging, and diagnostics tool for applications on Google Cloud Platform and AWS.
107
참고 답변
With advent of Cloud Computing organizations went from a fixed and predictable spending model to cloud driven variable spending model.
108
참고 답변
Any system that is supposed to be capable of healing itself needs to be able to handle faults and partitioning (i.e. when part of the system cannot access the rest of the system) to a certain extent. For databases, a common way to deal with partition tolerance is to use a quorum for writes. This means that every time something is written, a minimum number of nodes must confirm the write. The minimum number of nodes necessary to gracefully recover from a single-node fault is three nodes. That way the healthy two nodes can confirm the state of the system. For cloud applications, it is common to distribute these three nodes across three availability zones.
109
참고 답변
Reserved instances, spot instances, and savings plans can provide significant savings. What experience do they have with these options? Knowing their familiarity with these cost-saving mechanisms can highlight their strategic approach to cloud expenses.
110
참고 답변
An API (Application Programming Interface) is a set of protocols and tools for building software and applications.
111
참고 답변
I handle shared resources by implementing tagging strategies and using showback or chargeback models. Cost allocation is based on usage metrics and business context, ensuring transparency and fairness. This involves working with engineering to define appropriate allocation keys and leveraging tools like AWS Cost Explorer or Cloudability to distribute costs equitably.
112
참고 답변
A Service Level Objective (SLO) is a specific, measurable, and achievable internal target for a particular aspect of service performance or reliability. SLOs are a key component of Site Reliability Engineering (SRE) practices and are used to guide engineering decisions and balance reliability work with feature development. **Key Characteristics of an SLO:** 1. **Service-Specific:** Defined for a particular user-facing service or critical internal system. 2. **User-Focused:** Based on what matters to users (e.g., availability, latency, correctness). 3. **Measurable:** Quantifiable using specific metrics (SLIs). 4. **Target Value:** A specific numerical goal (e.g., 99.9% availability, 99th percentile latency < 200ms). 5. **Measurement Window:** The period over which the SLO is evaluated (e.g., rolling 28 days, calendar month). 6. **Internal Target:** Used by the team providing the service to manage and improve reliability. SLOs are typically stricter than any corresponding SLAs to provide a safety margin. **Purpose of SLOs:** * **Data-Driven Decisions:** Provide a quantitative basis for making decisions about reliability, such as when to invest in more resilient infrastructure or when to prioritize bug fixes over new features. * **Error Budgets:** SLOs directly define error budgets. An error budget is the amount of time or number of events a service can fail to meet its SLO without breaching it. For example, an SLO of 99.9% availability over 30 days allows for approximately 43 minutes of downtime (the error budget). * **Balancing Reliability and Innovation:** If the service is consistently meeting its SLOs (i.e., not consuming its error budget), the team can focus more on feature development. If the error budget is being consumed rapidly, the team must prioritize reliability work. * **Shared Understanding:** Creates a common language and understanding of reliability goals across development, operations, and product teams. * **Alerting:** SLO burn rates (how quickly the error budget is being consumed) are often used to trigger alerts, prompting action before the SLO is breached. **How to Define Good SLOs:** 1. **Identify Critical User Journeys (CUJs):** What are the most important things users do with the service? 2. **Choose Appropriate SLIs:** Select metrics that accurately reflect the user experience for those CUJs (e.g., request success rate, latency at a specific percentile). 3. **Set Achievable Targets:** Consider historical performance, user expectations, and business requirements. Don't aim for 100% if it's not necessary or feasible, as it can be prohibitively expensive and stifle innovation. 4. **Document and Communicate:** Ensure SLOs are well-documented and understood by all stakeholders. 5. **Iterate:** Regularly review and refine SLOs based on new data and changing requirements. **Example SLO:** * **Service:** User Login API * **SLI:** Percentage of successful login requests (HTTP 200 responses) over all valid login attempts. * **Target:** 99.95% * **Period:** Measured over a rolling 28-day window. * **Consequence (Internal):** If the error budget (0.05%) is exceeded, new feature development for the login service is paused, and all engineering effort is directed towards reliability improvements until the service is back within SLO.
113
참고 답변
Security plays a critical role in ensuring that software applications and systems are protected throughout their lifecycle. Here are critical aspects of security in DevOps: In DevOps, security is integrated into every phase of the software development lifecycle, from planning and coding to testing, deployment, and operations. This approach, known as DevSecOps, emphasizes proactive security measures rather than addressing vulnerabilities as an afterthought. DevOps promotes continuous monitoring of applications and infrastructure to promptly detect and respond to security incidents. Monitoring tools provide real-time visibility into system behavior, allowing teams to detect anomalies, unauthorized access attempts, or potential breaches. Automated responses and incident response plans help swiftly mitigate the impact of security incidents.
114
참고 답변
Our team needed to implement real-time log analysis, but our existing ELK stack couldn't handle the volume. My manager asked me to evaluate Amazon Kinesis, which I had never used. I spent a weekend going through AWS documentation and building a proof-of-concept. Within a week, I had learned Kinesis Data Streams and Kinesis Analytics well enough to design a solution that processed 50,000 log events per second. I also created documentation and trained my teammates on the new system. This experience taught me that I can quickly absorb new technologies when there's a clear business need.
115
참고 답변
Infrastructure Monitoring is the process of collecting and analyzing data from IT infrastructure components to ensure optimal performance and availability. Key components: Metrics Collection: - System metrics - Network metrics - Application metrics Analysis: Monitoring Areas: - Resource utilization - Performance metrics - Availability - Error rates - Response times
116
참고 답변
The component-based assembly model uses object-oriented technologies. In object-oriented technologies, the emphasis is on the creation of classes. Classes are the entities that encapsulate data and algorithms. In component-based architecture, classes (i.e., components required to build application) can be uses as reusable components.
117
참고 답변
Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications.
118
참고 답변
- A Dockerfile is used for creating Docker images using the build command. - With a Docker image, any user can run the code to create Docker containers. - Once a Docker image is built, it's uploaded in a Docker registry. - From the Docker registry, users can get the Docker image and build new containers whenever they want.
119
참고 답변
This question is quite common to assess your basic understanding of containers. | Feature | Docker | Virtual Machine | | Resource usage | Lightweight (shares OS kernel) | Heavy (full OS per VM) | | Startup time | Seconds | Minutes | | Isolation | Process-level | OS-level | | Use case | Microservices, CI/CD pipelines | Full-system emulation, isolation | Docker is fast, portable, and great for modern app workflows. VMs are still helpful for strict isolation and legacy systems. If you want to prepare more for Docker-related interview questions, I recommend reading Top 26 Docker Interview Questions and Answers for 2026.
120
참고 답변
Continuous Feedback in software testing is trying out an iterative process that involves presenting everyday comments, reviews, and critiques during the software program improvement lifecycle. It ensures that builders get an equal message approximately the quality and functionality of their code. Let's delve deeper into this concept little by little and discover the variations associated with it.
121
참고 답변
Yes, DevOps is part of agile methodology, with the main difference being that it can only be applied over the section on growth. Agile will, at the same time, be used for both processes and improvements.
122
참고 답변
My approach to handling untagged or orphaned resources involves establishing a robust, automated tagging policy, regularly auditing for compliance, and using automation tools to enforce policies and remediate non-compliance.
123
참고 답변
I've used both. IaaS offers more control, while PaaS simplifies management. The choice depends on the project's requirements.
124
참고 답변
A Docker image is a read-only template containing a set of instructions for creating a Docker container. It includes the application code, runtime, libraries, dependencies, and system tools.
125
참고 답변
Database DevOps is the practice of applying DevOps principles to database development and management. Key practices: 1. **Version Control:** - Schema versioning - Code-first approach - Migration scripts 2. **Automation:** Continuous Integration: - Automated testing - Schema validation - Data consistency checks Continuous Delivery: - Automated deployments - Rollback procedures - Data synchronization
126
참고 답변
I approach Reserved Instances for steady-state workloads to maximize savings, Savings Plans for flexibility across services, and Spot Instances for fault-tolerant or batch workloads to reduce costs further. The choice depends on workload patterns, risk tolerance, and commitment levels.
127
참고 답변
Maintaining previous stable versions, automated testing before deployment, and using tools that support instant rollbacks like Spinnaker.
128
참고 답변
- It is possible to run multiple containers as a single service with Docker Compose. - Here, each container runs in isolation but can interact with each other. - All Docker Compose files are YAML files.
129
참고 답변
Cloud Assessment is the process of evaluating the suitability of cloud services for a specific use case or workload. Key components: 1. **Assessment Criteria:** - Cloud service capabilities - Cost and pricing - Security and compliance - Performance and scalability - Disaster recovery and high availability 2. **Assessment Methodology:** - Cloud service comparison - Risk assessment - Cost-benefit analysis
130
참고 답변
The answer should emphasize evaluation first, using criteria like usage trends (increasing/decreasing), environment (production vs. dev/test), business criticality of the workload, and risk tolerance (potential impact of changes). Recommendations are prioritized based on risk/reward balance.
131
참고 답변
Regular audits, integrating compliance checks in the CI/CD pipeline, and employing best practices in infrastructure setup.
132
참고 답변
A developer working with a current branch wants to switch to another branch to work on something else, but the developer doesn't want to commit changes to your unfinished work. The solution to this issue is Git stash. Git stash takes your modified tracked files and saves them on a stack of unfinished changes that you can reapply at any time.
133
참고 답변
By using performance monitoring tools, conducting regular load testing, and optimizing infrastructure based on insights.
134
참고 답변
Version control isn't only valid for code, but for almost everything. In DevOps: - You version your code, infrastructure, and even documentation. - Git enables collaboration, rollback, and traceability. - Tools like GitHub Actions or GitLab CI/CD integrate directly with Git workflows for seamless automation. Version control is the heart of every DevOps infrastructure.
135
참고 답변
We once introduced a new feature and used A/B testing to gradually roll it out, comparing system performance and user feedback before a full-scale deployment.
136
참고 답변
Virtualization is the creation of virtual versions of physical resources like servers, storage devices, and networks.
137
참고 답변
Exceptions are events that occur during the execution of a program and disrupt the normal flow of a program's instructions. Selenium has the following exceptions: - TimeoutException: It is thrown when a command performing an operation does not complete in the stipulated time. - NoSuchElementException: It is thrown when an element with specific attributes is not found on the web page. - ElementNotVisibleException: It is thrown when an element is present in Document Object Model (DOM) but is not visible. Ex: Hidden Elements defined in HTML using type=“hidden”. - SessionNotFoundException: The WebDriver is performing the action immediately after quitting the browser.
138
참고 답변
Automatic discounts for consistently running workloads.
139
참고 답변
Compliance should be proactively integrated from the beginning of the software development cycle. Steps to follow: - Version control everything (code, infra, policies) - Audit trails through Git, CI/CD logs, and monitoring tools - Automated compliance checks (e.g., CIS benchmarks, security scanners) - Access control via RBAC and least-privilege - Secrets management with rotation policies
140
참고 답변
I communicate complex financial data by translating technical metrics into business outcomes using simple language, visual dashboards, and storytelling. For example, I use the '10-second rule' to present key insights quickly, focusing on actionable takeaways rather than raw numbers.
141
참고 답변
AWS is a DevOps powerhouse, offering CI/CD automation, infrastructure as code (IaC), container orchestration, monitoring, and security to streamline software development and deployment. - Key services like AWS CodePipeline, CodeBuild, and CodeDeploy automate CI/CD workflows, while CloudFormation and Terraform enable seamless infrastructure provisioning. - Amazon ECS, EKS, and Fargate manage containerized applications, and CloudWatch, X-Ray, and CloudTrail ensure real-time monitoring and security. - With Auto Scaling, ELB, and AWS Lambda, AWS enhances scalability, high availability, and serverless computing. Its integrations with Jenkins, GitHub, and Terraform make it a cost-effective, high-performance solution for cloud DevOps, ensuring faster deployments, optimized workflows, and secure cloud infrastructure.
142
참고 답변
Site Reliability Engineering (SRE) is a discipline that incorporates aspects of software engineering and applies them to infrastructure and operations problems to create scalable and highly reliable software systems. Key principles: Embrace Risk: - Define acceptable risk levels - Use error budgets - Balance reliability and innovation Eliminate Toil: - Automate manual tasks - Reduce operational overhead - Focus on engineering work
143
참고 답변
Infrastructure Automation is the process of scripting environments - from installing an operating system, to installing and configuring servers on instances, to configuring how the instances and software communicate with one another. Key components: Provisioning: - Resource creation - Configuration management - Application deployment Orchestration: - Workflow automation - Service coordination - Resource scheduling
144
참고 답변
In my previous role, I managed our AWS infrastructure, optimizing resource allocation and implementing cost-saving measures. I also have experience with Azure, where I set up and maintained scalable cloud services for our applications.
145
참고 답변
Selenium is capable of testing an application on an Android browser using an Android driver. You can use the Selendroid or Appium framework to test native apps or web apps in the Android browser. The following is a sample code:
146
참고 답변
Commonly used tools in FinOps for cloud cost management include: - CloudHealth: Provides visibility into cloud usage and costs, with reporting and policy management features. - AWS Cost Explorer and AWS Budgets: Native AWS tools for monitoring and managing cloud spending within AWS. - Google Cloud's Cost Management: Offers real-time cost monitoring and forecasting capabilities for GCP. - Azure Cost Management and Billing: Enables cost analysis, forecasting, and budgeting for Azure resources. - Kubecost: Helps track Kubernetes costs across clusters and provides optimization recommendations. These tools offer insights into cloud usage, forecast costs, and identify potential savings, which are essential for effective FinOps practices.
147
참고 답변
DevOps is a practice or a culture that allows the collaboration of the development team and the operations team to come together for successful product development. This involves making use of practices like continuous development, integration, testing, deployment, and monitoring of the SDLC cycle. DevOps tries to reduce the gap between the developers and the operations team for the effective launch of the product. Agile is nothing but a software development methodology that focuses on incremental, iterative, and rapid releases of software features by involving the customer by means of feedback. This methodology removes the gap between the requirement understanding of the clients and the developers.
148
참고 답변
Monitoring in DevOps is the practice of collecting and analyzing data about the performance and stability of services and infrastructure to improve the system's reliability. Key aspects include: Infrastructure Monitoring: - Server health - Network performance - Resource utilization Application Monitoring: - Response times - Error rates - Request rates User Experience Monitoring: - Page load times - User interactions - Conversion rates
149
참고 답변
Both offer similar services, but they have different user interfaces, pricing models, and specific services tailored to different needs.
150
참고 답변
Everyone loves saving money, right? Ask your candidate about the specific strategies they use to identify and slash wasted cloud spend. Are they fans of cost monitoring tools, or do they rely on manual audits? Their methods will reveal their capability to make cloud spending lean and efficient.
151
참고 답변
Pair programming is an Extreme Programming Principles Architecture technique. Two programmers function on the very same device in this form, on the same layout/algorithm/code. One programmer acts as a “horse,” and another acts as an “observer” who always watches a project's development to detect issues. With no intimation, the functions can be switched at any time.
152
참고 답변
Backup and Disaster Recovery (BDR) is a combination of data backup and disaster recovery solutions that work together to ensure an organization's business continuity. Key components: Data Backup: - Regular data copies - Multiple backup locations - Automated backup processes Disaster Recovery: - Recovery procedures - Failover systems - Business continuity plans
153
참고 답변
Continuous testing is a software testing practice that involves automating the testing process and integrating it into the continuous delivery pipeline. The goal of continuous testing is to catch and fix issues as early as possible in the development process before they reach production.
154
참고 답변
Vertical scaling means increasing the capacity of a single server (e.g., adding more CPU or memory), while horizontal scaling means adding more servers to distribute the load. From a finance perspective, vertical scaling can lead to higher costs per server due to premium hardware and potential downtime, while horizontal scaling often uses cheaper, commodity hardware and can be more cost-effective for variable workloads, but may increase management complexity and network costs.
155
참고 답변
For most projects, leveraging a managed service is more efficient and cost-effective because it reduces operational overhead, such as maintenance, patching, and scaling, which are handled by the provider. However, for highly customized or cost-sensitive projects with predictable workloads, installing software on a barebones machine may be cheaper, but it requires more engineering effort and expertise.
156
참고 답변
An antipattern is the opposite of a best practice. In DevOps, antipatterns occur when teams focus too much on short-term goals, like quick fixes or rapid releases, without thinking about the long-term impact. This often leads to poor collaboration, technical debt, or processes that don't scale well. As a result, long-term success becomes harder to achieve. The following table explain some common antipatterns and ways how to avoid it. | Antipattern | What's Wrong? | How to Avoid It | |---|---|---| | Siloed Teams | Dev and Ops work separately, causing delays and blame. | Encourage collaboration, shared responsibilities, and cross-functional teams. | | Manual Deployments | Slow and error-prone, leads to inconsistent environments. | Use CI/CD tools like Jenkins, GitHub Actions to automate builds and deployments. | | One-Person Knowledge | Only one person knows key processes; creates a single point of failure. | Share knowledge via documentation, pair programming, and team training. | | Ignoring Monitoring & Logs | No visibility into issues after deployment; hard to troubleshoot. | Set up monitoring (Prometheus/Grafana) and logging (ELK Stack, Loki) with alerts. | | Too Much Focus on Tools | Relying only on tools without building a DevOps culture. | Focus on team culture, communication, automation, and continuous improvement. |
157
참고 답변
Ansible is an open-source automation tool used for configuration management, application deployment, and task automation. It helps system administrators and DevOps teams manage multiple servers from a single control machine without needing to install any agents on the target systems. - Agentless: Works over SSH, no extra software required on client machines. - Simple Language: Uses YAML (called Playbooks) to describe automation tasks in human-readable form. - Scalable: Can manage from a few servers to thousands. - Flexible: Supports tasks like provisioning, patching, orchestration, and cloud automation. Example Use Case: Deploying a web application across 50 servers with one command, ensuring every server has the same configuration..
158
참고 답변
Virtualization offers several benefits in a DevOps environment, including: - Improved efficiency: Virtualization allows for faster creation, deployment, and management of development and testing environments. - Greater scalability: Virtualization enables teams to quickly scale up or down their infrastructure as needed without requiring additional physical hardware. - Increased flexibility: Virtualization allows the creation of custom environments that can be easily modified and adapted to meet changing requirements. - Reduced costs: Virtualization can help reduce hardware costs and increase resource utilization, leading to lower overall infrastructure costs.
159
참고 답변
The FinOps lifecycle can be seen as a continuing three-step process since FinOps adopts an iterative approach to managing cloud money. Inform FinOps depends on clear insight into resources, budgeting, benchmarking, and other factors to support organizations' and teams' ability to make real-time decisions. The organization will be better equipped to control cloud expenditures the more informed they are about visibility and allocation. Optimize After gathering the necessary data, the firm must now move to cut spending and correctly scale capacity without lowering cloud effectiveness. Optimization is examining utilization and rates with a critical eye and making the required adjustments. Operate Organizations must evaluate efficacy after eliminating extraneous items. They measure cloud capacity's efficiency, cost, and quality and compare the findings to predetermined benchmarks. For continuing FinOps optimization, the company repeatedly restarts the cycle as changes are made and tested. It's critical to remember that this cycle depends on the team and is not merely self-repeating. An organization could be in various phases in different departments and at different times.
160
참고 답변
Challenges in stakeholder adoption include resistance to accountability and lack of cost visibility, which can be addressed by communicating value in business terms, providing actionable dashboards, and integrating FinOps into sprint reviews and quarterly planning.
161
참고 답변
The approach involves immediate investigation to identify the source (e.g., by service, region, or tag), assessing if it's due to a legitimate business need or an error, and then taking corrective actions such as stopping unused resources or implementing limits.
162
참고 답변
Rate Limiting is a technique used to control the rate at which requests are processed or transmitted. Key concepts: Token Bucket Algorithm: - Fixed number of tokens - Tokens are replenished at a fixed rate - Tokens are consumed at a variable rate Leaky Bucket Algorithm: - Fixed size bucket - Water leaks out at a fixed rate - Water is added at a variable rate Example of Nginx Rate Limiting configuration: http { limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; server { location / { limit_req burst=5 nodelay; } } }
163
참고 답변
A Service Level Indicator (SLI) is a quantitative measure of some aspect of the level of service provided to users. SLIs are the raw data points or metrics used to assess performance against Service Level Objectives (SLOs). They are crucial for objectively understanding how a service is performing from a user's perspective. **Key Characteristics of an SLI:** 1. **Quantitative Measure:** A specific, numerical value derived from system telemetry. 2. **User-Centric:** Reflects an aspect of service performance that directly impacts user experience. 3. **Directly Measurable:** Can be obtained from monitoring systems, logs, or other data sources. 4. **Good Proxy for User Happiness:** A change in the SLI should correlate with a change in user satisfaction. 5. **Reliably Measured:** The measurement itself should be accurate and dependable. **Common Types of SLIs:** * **Availability:** Measures the proportion of time the service is usable or the percentage of successful requests. * *Example:* (Number of successful HTTP requests / Total valid HTTP requests) * 100%. * **Latency:** Measures the time taken to serve a request. Often measured at specific percentiles (e.g., 95th, 99th percentile) to understand typical and worst-case performance. * *Example:* The 99th percentile of API response times for the `/users` endpoint over the last 5 minutes. * **Error Rate:** Measures the proportion of requests that result in errors. * *Example:* (Number of HTTP 5xx responses / Total valid HTTP requests) * 100%. * **Throughput:** Measures the rate at which the system processes requests or data. * *Example:* Requests per second (RPS) handled by the shopping cart service. * **Durability:** Measures the likelihood that data stored in the system will be retained over a long period without corruption. * *Example:* Probability of a stored object remaining intact and accessible after one year. * **Correctness/Quality:** Measures if the service provides the right answer or performs the right action. * *Example:* Percentage of search queries that return relevant results, or proportion of financial transactions processed without data errors. **How to Choose Good SLIs:** 1. **Focus on User Experience:** What aspects of performance or reliability are most important to your users? 2. **Keep it Simple:** Choose a small number of meaningful SLIs rather than trying to track everything. 3. **Ensure it's Actionable:** The SLI should provide data that can lead to improvements or inform decisions. 4. **Distinguish from Raw Metrics:** While SLIs are derived from metrics, they are specifically chosen and often processed (e.g., aggregated, percentiled) to represent service level. **Relationship with SLOs and SLAs:** * SLIs are the **measurements**. * SLOs are the **targets** for those measurements (e.g., SLI for availability >= 99.9%). * SLAs are the **agreements** with users, often based on achieving certain SLOs, and typically include consequences if not met. **Example:** * **User Journey:** User uploads a photo. * **Possible SLIs:** * `upload_success_rate`: (Number of successful photo uploads / Total photo upload attempts) * 100% * `upload_latency_p95`: 95th percentile of time taken from initiating upload to confirmation. * **Corresponding SLO for `upload_success_rate` might be:** 99.9% over a 7-day window.
164
참고 답변
The answer should demonstrate familiarity with S3 storage classes (Standard, Infrequent Access, Glacier, etc.) and describe an archival strategy using Glacier for data that is rarely accessed, with lifecycle policies to automatically transition objects to lower-cost tiers based on age.
165
참고 답변
Transparency is key. How does your candidate keep stakeholders in the loop regarding cloud spending? Do they use detailed reports, regular updates, or interactive dashboards? Effective communication ensures everyone is on the same page financially.
166
참고 답변
Test automation or manual testing Automation is the process of automating a manual procedure to test an application or system. It entails using independent testing tools to develop test scripts that can be run repeatedly without the need for human interaction.
167
참고 답변
Cloud Migration Tools are software tools that help automate the migration of applications and data to cloud platforms. Key components: 1. **Data Migration Tools:** - Database migration tools - Application migration tools - Data synchronization tools 2. **Application Migration Tools:** - Application packaging tools - Application containerization tools - Application serverless tools 3. **Migration Orchestration Tools:** - Workflow automation tools - Service coordination tools - Resource scheduling tools
168
참고 답변
Negotiation skills are invaluable. Ask about their experience in securing favorable contracts or discounts with cloud service providers. What tactics did they use, and what were the outcomes? This question sheds light on their ability to reduce costs through negotiation.
169
참고 답변
- Docker uses a client-server architecture. - Docker Client is a service that runs a command. The command is translated using the REST API and is sent to the Docker Daemon (server). - Docker Daemon accepts the request and interacts with the operating system to build Docker images and run Docker containers. - A Docker image is a template of instructions, which is used to create containers. - Docker container is an executable package of an application and its dependencies together. - Docker registry is a service to host and distribute Docker images among users.
170
참고 답변
This question tests your leadership and team collaboration skills. Some ideas for onboarding junior engineers: - Creating a “Getting Started” documentation page with all relevant information and links - Pair programming or co-debugging sessions - Documenting runbooks and workflows - Creating sandbox environments for safe experimentation - Hosting internal workshops on Docker/Kubernetes basics The difference between a good and a great engineer lies in teaching skills.
171
참고 답변
Answers typically contrast cost reporting from cloud providers against workload performance, availability and a consideration of pooled/available cloud resources and services. For example, how is a workload evaluated against its expectations for performance and availability? Similarly, how can cloud costs be reduced, such as through smaller instances or committed use models, while maintaining or improving performance and availability to accommodate future growth? This discussion often involves the use of tools, metrics and KPIs in the decision-making process.
172
참고 답변
In FinOps, budgets are set by establishing spending limits for teams, departments, or projects based on historical data and forecasts. Cloud providers like AWS, Google Cloud, and Azure offer tools to set budget thresholds and receive alerts when usage approaches the limit. Monitoring spending relative to budgets is crucial, and teams can leverage automated notifications to avoid budget overruns. Budgeting in FinOps enables teams to stay within financial limits, while providing flexibility for scaling and adapting to changes in demand.
173
참고 답변
Yes, I implemented a champion program where engineers were empowered with real-time cost visibility and given ownership of optimization within their domains. By using gamification and leaderboards, we motivated teams to reduce waste without imposing rigid approvals, ensuring delivery speed was maintained while fostering accountability.
174
참고 답변
Azure Blob Storage is a service for storing large amounts of unstructured object data, such as text or binary data.
175
참고 답변
DevOps metrics are measurements used to evaluate the performance and efficiency of DevOps practices and processes. Key categories: 1. **Velocity Metrics:** - Deployment frequency - Lead time for changes - Time to market 2. **Quality Metrics:** - Change failure rate - Bug detection rate - Test coverage 3. **Operational Metrics:** Performance: - Application response time - Error rates - Resource utilization Reliability: - System uptime - MTTR - MTBF
176
참고 답변
Effective strategies for continuous delivery using infrastructure automation include employing versioned infrastructure as code, using blue-green or canary deployments, integrating rollback mechanisms, automating environment provisioning, and implementing zero-downtime deployment patterns.
177
참고 답변
I have used tools such as AWS Config Rules, Azure Policy, and automation to enforce policies and remediate non-compliance for accurate allocation.
178
참고 답변
A Service Level Agreement (SLA) is a formal, externally-facing contract or commitment between a service provider and its customers (or users). It defines the specific level of service that will be provided, including metrics, responsibilities, and remedies or penalties if the agreed-upon service levels are not met. **Key Components of an SLA:** 1. **Service Description:** Clearly defines the service being provided. 2. **Parties Involved:** Identifies the service provider and the customer. 3. **Agreement Period:** Specifies the duration for which the SLA is valid. 4. **Service Availability:** Defines the expected uptime or availability of the service (e.g., 99.9% uptime per month). 5. **Performance Metrics:** Specifies key performance indicators (KPIs) and their targets (e.g., API response time, data processing throughput). 6. **Responsibilities:** Outlines the duties of both the service provider and the customer. 7. **Support and Escalation Procedures:** Details how support will be provided, response times for issues, and how problems will be escalated. 8. **Exclusions:** Lists conditions or events that are not covered by the SLA (e.g., scheduled maintenance, force majeure). 9. **Remedies or Penalties (Service Credits):** Describes the compensation or actions (e.g., service credits, discounts) if the provider fails to meet the SLA terms. 10. **Reporting and Monitoring:** Specifies how service performance will be tracked and reported to the customer. **Purpose in DevOps/SRE:** * **Sets Expectations:** Clearly communicates to users what level of service they can expect. * **Drives Reliability Efforts:** While SLAs are external, they often drive internal targets (SLOs) to ensure commitments are met. * **Accountability:** Provides a basis for holding the service provider accountable for performance. * **Business Alignment:** Helps align IT services with business needs and user expectations. **Distinction from SLOs and SLIs:** * **SLA (Agreement):** The formal contract with consequences. * **SLO (Objective):** Internal targets set by the service provider to meet or exceed the SLA. SLOs are typically stricter than SLAs to provide a buffer. * **SLI (Indicator):** The actual measurements of service performance (e.g., measured uptime, actual response time). SLIs are used to track performance against SLOs. **Example SLA Clause for Availability:** "The Service Provider guarantees 99.9% Uptime for the Service during any calendar month. Uptime is defined as the percentage of time the Service is accessible and functioning correctly. If Uptime falls below 99.9% in a given month, the Customer will be eligible for a Service Credit of 5% of their monthly service fee for that month."
179
참고 답변
Common monitoring tools used in DevOps: Infrastructure Monitoring: - Prometheus - Nagios - Zabbix - Datadog Application Monitoring: Tools: - New Relic - AppDynamics - Dynatrace Features: - Transaction tracing - Error tracking - Performance analytics
180
참고 답변
I use centralized configuration management tools like Consul or Etcd. They store and manage configuration in a distributed manner, ensuring all nodes have consistent configurations.
181
참고 답변
There are several applications or user stories that are created, tested, and ready for implementation in an Agile Sprint, For Instance. But not everyone will be implemented depending on the client's requirements and goals. But it's essential to keep the code readily accessible for distribution here in continuous Delivery. In Continuous Deployment, all the improvements made by the developer go through different stages to be delivered in an automated fashion into the PRODUCTION circumstances.
182
참고 답변
- Jenkins master pulls the code from the remote GitHub repository every time there is a code commit. - It distributes the workload to all the Jenkins slaves. - On request from the Jenkins master, the slaves carry out, builds, test, and produce test reports.
183
참고 답변
A service and a microservice are both architectural patterns for building and deploying software applications, but there are some key differences between them:
184
참고 답변
FinOps is not just about cost numbers; it is a cultural practice that balances cost, speed, and quality. To position its value: for engineering, emphasize enabling innovation with cost-aware decisions and automation; for finance, highlight budgeting accuracy, forecasting, and compliance; for product teams, demonstrate ROI alignment and trade-off analysis to support feature prioritization.
185
참고 답변
The answer should describe experience with showback (providing cost visibility to teams without actual billing) or chargeback (allocating costs to specific business units), using tools like AWS Cost Allocation Tags, custom dashboards, or third-party software to track and report usage by team.
186
참고 답변
The effectiveness of FinOps is typically measured by a variety of metrics. A job candidate should understand the importance of tracking and reporting FinOps results. Although there is no universally accepted suite of FinOps metrics, several common measures exist, such as allocation, forecasting and enablement. Some important metrics include: Cloud allocation (percentage of total cloud costs allocated to workload owners), Cloud enablement (percentage of an organization's business leaders trained in FinOps), Cost forecasting (actual cloud spending versus the amount planned), Cost optimization (ratio of total cloud services optimized versus total cloud services used), and Recommendations implemented (number of recommendations from tools provided versus the total number implemented). Other recognized cloud metrics or KPIs include factors such as resource utilization rate, RI utilization, cost per customer, allocated cloud spend and percentage of wasted spend.
187
참고 답변
DevOps best practices are proven methods that enhance software development and delivery. Key practices: Technical Practices: - Infrastructure as Code - Continuous Integration - Automated Testing - Continuous Deployment - Monitoring and Logging Cultural Practices: - Shared Responsibility - Blameless Post-mortems - Knowledge Sharing - Continuous Learning - Cross-functional Teams Process Practices: - Agile Methodology - Version Control - Configuration Management - Release Management - Incident Management
188
참고 답변
Continuous Delivery is an application of Continuous Development that aims to bring the developers' functionality to the end-users as quickly as possible. During this process, it goes through different stages of QA, Planning, etc., and then into the Manufacturing system for distribution.
189
참고 답변
Tagging is crucial for tracking expenses. How does your candidate set up and enforce a tagging strategy to ensure accurate cost tracking? Their tagging strategy can reveal their attention to detail and organizational skills.
190
참고 답변
Ansible has two types of servers categorized as: - Controlling machines - Nodes For this to work, Ansible is installed on controlling machine using which the nodes are managed by means of using SSH. The location of the nodes would be specified and configured in the inventories of the controlling machine. Ansible does not require any installations on the remote node servers due its nature of being agentless. Hence, no background process needs to be executed while managing any remote nodes. Ansible can manage lots of nodes from a single controlling system my making use of Ansible Playbooks through SSH connection. Playbooks are of the YAML format and are capable to perform multiple tasks.
191
참고 답변
Chaos engineering involves intentionally injecting failures into your systems to test resilience. Example tools: - Gremlin - Chaos Monkey - Litmus Scenarios simulated to test your system's stability include: - Killing of random pods - Simulate network latency - Drop DB connections Chaos engineering is also heavily used by Netflix. It helps to simulate different scenarios and see how your system behaves.
192
참고 답변
Continuous Integration (CI) is a development practice where developers integrate code into a shared repository frequently, preferably several times a day. Each integration can then be verified by an automated build and automated tests. Key aspects of CI include: - Maintaining a single source repository - Automating the build - Making the build self-testing - Everyone commits to the baseline every day - Every commit builds on an integration machine - Keep the build fast - Test in a clone of the production environment - Make it easy to get the latest deliverables - Everyone can see the results of the latest build - Automate deployment
193
참고 답변
Scalability is the capability of a system to handle a growing amount of work by adding resources to the system. There are two types of scaling: Vertical Scaling (Scale Up): - Adding more power to existing resources - Example: Upgrading CPU/RAM Horizontal Scaling (Scale Out): - Adding more resources - Example: Adding more servers
194
참고 답변
- Enables management of and changes to multiple systems. - Standardizes resource configurations, which in turn, manage IT infrastructure. - It helps with the administration and management of multiple servers and maintains the integrity of the entire infrastructure.
195
참고 답변
I have worked as a liaison between finance and engineering teams, facilitating communication and aligning goals. For example, I collaborated with engineers to forecast cloud infrastructure costs and with finance to create budgets, ensuring both teams understood the trade-offs between cost, speed, and quality in cloud spending.
196
참고 답변
Best practices for implementing FinOps include: - Establish clear tagging policies: Standardize tagging across the organization for accurate cost allocation. - Automate cost optimization: Use tools to automate rightsizing, scheduling, and reserved instance purchases. - Foster cross-functional collaboration: Ensure finance, engineering, and operations work together to manage cloud spending. - Implement real-time cost monitoring: Enable proactive adjustments with real-time visibility. - Regularly review and adjust budgets: Analyze spending trends and adjust budgets based on usage patterns. By following these best practices, organizations can create a sustainable FinOps program, enabling efficient and accountable cloud cost management.
197
참고 답변
This is a method of continuous deployment commonly used to reduce downtime. Traffic is transferred from one instance to another. To include a fresh version of the code, we must replace the old code with a new version. The new version exists in a green environment, and the old one in a blue environment. After making changes to the previous version, we need a new instance from the old one to execute a newer version of the instance.
198
참고 답변
High Availability (HA) is a characteristic of a system that aims to ensure an agreed level of operational performance, usually uptime, for a higher than normal period. Key components: Redundancy: - Multiple instances - No single point of failure Monitoring: - Health checks - Automated failover Load Balancing: - Traffic distribution - Resource optimization
199
참고 답변
DevOps is essential because it improves collaboration and communication between development and operations teams, speeds up the delivery of software products, enhances the quality and reliability of software releases, and allows for faster recovery from failures.
200
참고 답변
The Container Network Interface (CNI) is an API specification that is focused around the creation and connection of container workloads. CNI has two main commands: add and delete. Configuration is passed in as JSON data. When the CNI plugin is added, a virtual ethernet device pair is created and then connected between the Pod network namespace and the Host network namespace. Once IPs and routes are created and assigned, the information is returned to the Kubernetes API server. An important feature that was added in later versions is the ability to chain CNI plugins.