1

참고 답변

Database changes can be managed in CI/CD pipelines by using tools like Liquibase or Flyway. These tools automate database migrations, ensuring that any changes to the database schema are consistent and versioned, just like code changes. The database migration process is integrated into the pipeline, allowing for smooth deployments and minimizing the risk of database inconsistencies.

2

참고 답변

Flaky tests destroy trust in the CI/CD pipeline. If developers ignore red builds, broken code will reach production. I would immediately isolate the flaky test by moving it out of the critical deployment pipeline and into a separate, non-blocking "Quarantine" pipeline that runs nightly. This turns the main CI pipeline green again, restoring trust. I then assign a ticket to the engineering team to investigate the root cause of the flakiness (often timing issues or shared database state) and only reintroduce it to the main pipeline once it achieves a 100% pass rate over a week.

3

참고 답변

Hosted CI/CD platforms are typically run on infrastructure that we manage ourselves, giving us more control over the environment but also requiring more maintenance. Cloud-based platforms, on the other hand, run in the cloud and offer scalability and managed maintenance. We currently use a cloud-based platform because it provides the flexibility and scalability we need without the overhead of managing the underlying infrastructure.

4

참고 답변

Blue-Green deployment maintains two environments: Blue (current production) Green (new version) Traffic flips post-validation only, so you can do zero-downtime and easy rollbacks.

5

참고 답변

The trunk-based development approach ensures software remains up-to-date by integrating small, frequent updates into the main branch or a core "trunk". As a result of its ability to streamline merging and integration phases, it can be used to achieve CI/CD and to increase the speed and efficiency of the delivery of software and the efficiency of organizations. It is a branching model that consists of most of the work happening in a single trunk (also known as the trunk, master, or main). Each developer in the team merges their changes into the trunk on a daily basis. The reason why trunk-based development is popular is that it simplifies version control. This model minimizes merge conflicts due to the trunk's single source of truth.

6

참고 답변

Continuous testing is the practice of applying automated tests early, gradually, and adequately in the software delivery pipeline. In a typical CI/CD workflow, builds are released in small batches. Therefore, it is impractical to manually perform test cases for each delivery. Automated continuous testing eliminates the manual steps and turns them into automated routines, which reduces human effort. That's why automated continuous testing is essential for the DevOps culture. Benefits of continuous testing: - Ensures the quality and speed of builds - Enables faster software delivery and a continuous feedback mechanism - Detects errors as soon as they occur in the system - Reduces business risks and evaluates potential problems before they become real problems

7

참고 답변

The process is pretty much the same as it was described above, with an added step to set up the actual Kubernetes cluster: Use Terraform to define and provision Kubernetes clusters in each cloud. For instance, create an EKS cluster on AWS, an AKS cluster on Azure, and a GKE cluster on Google Cloud, specifying configurations such as node types, sizes, and networking. Once you're ready, make sure to set up the Kubernetes auto-scaler on each of the cloud providers to manage resources and scale based on the load they receive.

8

참고 답변

Merging consists of joining branches. For example, when developers incorporate their peer-reviewed changes from a feature branch into the main branch.

9

참고 답변

CI/CD positively impacts software quality by enabling rapid and frequent testing of new code changes. Key ways it improves software quality include: - Automated Testing: Frequent automated tests ensure that issues are caught early, reducing defects in production. - Frequent Releases: Smaller, frequent releases help catch bugs and errors earlier in the development process, reducing the risk of large-scale failures. - Code Reviews: Integration of automated code reviews in CI processes ensures that high-quality code is pushed to production.

10

참고 답변

Continuous Deployment is the next phase in the CI/CD pipeline wherein every change in the code that passes the automated testing phase is automatically deployed to production. This guarantees that your software is always in a release-ready state. The main advantage of Continuous Deployment is it enables regular and frequent releases, elevating the responsiveness towards customers' needs, and accelerating feedback loops. It reduces the costs, time, and risks of the delivery process, eliminating the need for 'Deployment Day' which can often be a source of stress. Also, by delivering in smaller increments, you minimize the impact of any problem that might occur due to a release, making problems easier to troubleshoot and fix. Furthermore, the practice drives productivity as developers can focus on writing code, knowing that the pipeline will reliably take care of the rest.

11

참고 답변

Toggle features on or off in production without code modifications. Excellent for rollback without deployment, progressive rollouts, and A/B testing.

12

참고 답변

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.

13

참고 답변

Test coverage measures how much of the code is tested. Higher coverage indicates better testing reliability.

14

참고 답변

CI/CD provides visibility into code changes, automated feedback through testing, faster integration, and shared pipelines for communication. Real-World Scenario: A team uses CI/CD to see code change impacts immediately, fostering quick collaboration and issue resolution.

15

참고 답변

I would first assess the impact and severity, then immediately trigger a rollback to the last known stable version using automated rollback mechanisms (e.g., reverting traffic in blue-green deployment). Simultaneously, I would notify the team and stakeholders, and begin root cause analysis by reviewing logs, metrics, and pipeline outputs. After resolving the issue, I would add preventive measures like enhanced testing, canary stages, or failure detection to avoid recurrence.

16

참고 답변

Continuous Integration (CI) is a practice where developers integrate code changes into a shared repository multiple times a day. Each change triggers an automated build and test process to detect integration errors early. Real-World Scenario: A team developing a mobile banking app uses CI to merge code changes daily. Automated tests catch a bug in a new payment feature before it reaches production, saving time and preventing user complaints.

17

참고 답변

- CI: Code is automatically tested and merged - Continuous Delivery: Manual trigger, code is ready to deploy at any time - Continuous Deployment: After passing all tests, completely automated delivery to production

18

참고 답변

Serverless runners spin up fresh for every build and are destroyed immediately after, meaning traditional local caching (like a .m2 or node_modules folder sitting on a disk) is impossible. Without a cache, build times skyrocket. | Caching Strategy | Traditional VM Runner | Ephemeral Serverless Runner | |---|---|---| | Storage Location | Local SSD drive. | Remote Object Storage (AWS S3 or GCS). | | Pipeline Action (Start) | Checks local disk for existing cache. | Downloads the compressed cache tarball from S3 before compiling. | | Pipeline Action (End) | Leaves updated files on the disk for the next run. | Compresses the new dependencies and uploads the artifact back to S3. | By utilizing a remote S3 backend plugin for the CI tool, the serverless runners pull down the cache in seconds, dramatically reducing dependency resolution time while maintaining the security benefits of ephemeral compute.

19

참고 답변

I usually monitor several key metrics to ensure the CI/CD pipeline runs smoothly. Build success rate is one of the most important; it helps me understand how often builds are passing versus failing. Another critical metric is build duration, which tracks how long it takes for a build to complete. This is crucial for identifying bottlenecks and optimizing the pipeline for faster delivery. I also keep an eye on deployment frequency and lead time for changes. These metrics provide insights into how often changes are deployed to production and how long it takes from committing code to having it running in production. Additionally, failure rate and mean time to recovery (MTTR) are vital for assessing the stability and robustness of the pipeline. These metrics help quickly identify issues and measure how long it takes to resolve them, ensuring minimal downtime and disruption.

20

참고 답변

Automation streamlines and accelerates the CI/CD pipeline, ensuring consistent and reliable software delivery.

21

참고 답변

A CI/CD pipeline plays an essential role in automating the integration and delivery processes in software development. It allows for: - Efficient Code Integration: Continuous integration ensures that code changes are automatically merged into the shared repository without conflicts. - Automated Testing: Automated tests are triggered during integration to detect bugs and ensure code quality. - Frequent Delivery: Continuous delivery automates the deployment of code to staging or production, ensuring faster releases.

22

참고 답변

AWS provides a highly scalable and flexible cloud infrastructure for hosting and deploying applications, making it easier for DevOps teams to manage and scale their software systems. Moreover, it offers a range of tools and services to support continuous delivery, such as AWS CodePipeline and AWS CodeDeploy, which automate the software release process. AWS CloudFormation and AWS OpsWorks allow automation of the management and provisioning of infrastructure and applications. Then we have Amazon CloudWatch and Amazon CloudTrail, which enable the teams to monitor and log the performance and behavior of their software systems, ensuring reliability and security. AWS also supports containerization through Amazon Elastic Container Service and Amazon Elastic Kubernetes Service. It also provides serverless computing capabilities through services such as AWS Lambda. In conclusion, AWS offers a range of DevOps tools for efficient and successful DevOps implementation.

23

참고 답변

A Git branch is an independent line of development, usually created for working on a feature. Branches let developers code without affecting the work of other team members.

24

참고 답변

- Integration with Legacy Systems: Older systems may not be compatible with modern CI/CD practices, requiring additional work for integration. - Tooling Complexity: Managing multiple tools and technologies for different stages of the pipeline can become complex. - Test Automation: Ensuring reliable and comprehensive automated tests for different parts of the application. - Pipeline Configuration: Setting up a CI/CD pipeline that is flexible, reliable, and scales with the growth of the application.

25

참고 답변

A container is a runtime instance of a container image (which is a lightweight, executable package that includes everything needed to run your code). It is the execution environment that runs the application or service defined by the container image. When a container is started, it becomes an isolated process on the host machine with its own filesystem, network interfaces, and other resources. Containers share the host operating system's kernel, making them more efficient and quicker to start than virtual machines. A virtual machine (VM), on the other hand, is an emulation of a physical computer. Each VM runs a full operating system and has virtualized hardware, which makes them more resource-intensive and slower to start compared to containers.

26

참고 답변

Caching reduces build and test time by storing intermediate results such as dependencies, build artifacts, or Docker layers. When enabled, subsequent pipeline runs can reuse these cached items, avoiding the need to re-download or recompile them. Proper cache management improves efficiency, especially for large projects with many dependencies.

27

참고 답변

Dependencies can be managed using dependency management tools (e.g., Maven, npm), ensuring consistent environments, and automating dependency updates.

28

참고 답변

It's a strategy to reduce downtime and risk: - Blue Environment: Current live system - Green Environment: New version Once tested, traffic is rerouted from blue to green. ? Bonus: Talk about rollback strategies and traffic routing tools like NGINX or load balancers.

29

참고 답변

Selenium is a very well-known open-source software suite, mainly used for testing web browsers and web applications by automating some processes. It comes with a set of tools and libraries that allow developers or testers to automate some functions related to web browsers and web applications. Selenium Tool suite consists of 4 major components: - Selenium IDE (Integrated Development Environment) - Selenium WebDriver - Selenium Grid - Selenium Remote Control (Deprecated)

30

참고 답변

I would configure CI/CD to support deployments to multiple clouds or regions by using a cloud-agnostic orchestration tool like Terraform to define infrastructure, and parameterizing pipeline stages with environment variables for cloud provider credentials, region-specific configurations, and resource endpoints. The pipeline would run parallel deployment jobs for each region, with health checks and rollback logic, and use a centralized artifact repository to ensure consistent builds across clouds.

31

참고 답변

Container registries like Docker Hub, Amazon ECR, or GitHub Container Registry store and distribute Docker images built during the CI pipeline. Once a container is built, it's pushed to the registry as a versioned artifact. The CD pipeline then pulls the image from the registry and deploys it to the desired environment.

32

참고 답변

Logging for a distributed system is definitely not a trivial problem to solve. While the actual implementation might change based on your particular tech stack, the main aspects to consider are: Keep the structure of all logs consistent and the same throughout your platform. This will ensure that whenever you want to explore them in search for details, you'll be able to quickly move from one to the other without having to change anything. Centralize them somewhere. It can be an ELK stack, it can be Splunk or any of the many solutions available out there. Just make sure you centralize all your logs so that you can easily interact with all of them when required. Add unique IDs to each request that gets logged, that way you can trace the flow of data from service to service. Otherwise, debugging problems becomes a real issue. Add a tool that helps you search, query, and visualize the logs. After all, that's why you want to keep track of that information, to use it somehow. Find yourself a UI that works for you and use it to explore your logs.

33

참고 답변

The success of a CI/CD pipeline can be evaluated based on several key metrics that combine to demonstrate the efficiency of your development and delivery process. Firstly, successful deployments versus failed ones is a fundamental measure. A high success rate translates to a healthy pipeline, whereas repeated failures demand investigation and resolution. Lead time for changes — the time from code commit to that code being deployed to production — is another key metric. A shorter lead time means you are delivering value to your customers faster. The frequency of deployment can also offer insights. More frequent deployments usually point towards a more efficient and responsive development process. Monitoring the time to recovery can be insightful as well. If something goes wrong, how quickly can you restore service? Quicker recovery times generally mean your pipeline is well-architected to handle failure scenarios. Finally, looking at your test pass frequency and time taken for tests can help gauge how effectively you are identifying problems before they reach production. Together, these measures provide a well-rounded view of the effectiveness of your CI/CD pipeline. Yet, no single metric can define success; it's a mix of all of them aligned with your goals and your team's ability to continuously learn and improve.

34

참고 답변

Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud. Prometheus employs a pull-based model, where it regularly scrapes (pulls) metrics from endpoints exposed by the systems being monitored. This model is well-suited for dynamic and containerized environments. Prometheus Query Language (PromQL) is a powerful query language that allows users to retrieve and analyze metrics data. It supports various aggregation functions, filtering, and mathematical operations. Prometheus includes a built-in alerting system that allows users to define alert rules based on metric thresholds or conditions. When an alert is triggered, Prometheus can send notifications to external systems.

35

참고 답변

A CI pipeline is an automated workflow that builds, tests, and validates new code before merging it into production. - Steps: Code Commit → Build → Test → Artifact Storage → Deployment - Example tools: Jenkinsfile, GitHub Actions YAML, GitLab CI/CD YAML

36

참고 답변

Long-running tests slow down deployments. Strategies to optimize: - Parallel Test Execution: Run tests across multiple machines. - Test Selection: Run only impacted tests using test impact analysis. - Mocking Dependencies: Reduce external calls using Mockito, WireMock. - Shift-Left Testing: Run tests early in the pipeline to detect failures faster.

37

참고 답변

Shift-Left Testing also moves testing closer to the development stage of the pipeline, which lowers defect cost and allows faster developer feedback.

38

참고 답변

A CI/CD pipeline is an automated workflow that includes code integration, testing, and deployment stages.

39

참고 답변

GitOps uses Git as the source of truth for deployments. Changes in Git auto-sync to clusters. Tools: ArgoCD, Flux

40

참고 답변

A Docker image is a lightweight, standalone, and executable package containing everything needed to run a piece of software, including code, runtime, libraries, and dependencies. It serves as a blueprint for containers, defining the environment in which the application will run. Docker images are created through a build process and stored in a repository, ready for deployment. A Docker container is an instance of a Docker image that runs as a separate process on the host machine. While the image defines the environment, the container is the actual running instance that can execute commands and interact with other services. Containers are ephemeral, meaning they can be stopped and started easily, providing flexibility and consistency for CI/CD environments by ensuring that applications run consistently across different stages.

41

참고 답변

CI ensures that code changes are integrated and tested frequently, leading to early issue detection and faster development cycles.

42

참고 답변

Implementing regular backups, multi-region deployment, and having a documented and tested disaster recovery plan in place.

43

참고 답변

Assess the current state, choose appropriate CI/CD tools, configure pipelines, migrate code and tests, and ensure smooth transitions with minimal disruptions.

44

참고 답변

Testing is a core part of our CI process. We automate various types of tests, including unit tests, integration tests, and functional tests, to validate code correctness as early as possible. These tests run automatically whenever new code is committed, providing us with quick feedback on the quality and stability of our codebase.

45

참고 답변

Cloud providers offer on demand infrastructure, managed services, autoscaling, and CI/CD integrations all essential for building fast, reliable DevOps pipelines.

46

참고 답변

The build stage is where our source code is compiled into executable artifacts and packaged for deployment. It involves tasks like compiling code, running static analysis, and creating deployable packages. It is a critical step in ensuring that our code is ready to be deployed to different environments.

47

참고 답변

Selenium IDE (Integrated Development Environment) is an open-source web testing solution. Selenium IDE is like a tool that records what you do on a website. Subsequently, these recorded interactions can be replayed as automated tests. You don't need much programming skills to use it. Even if you're not great at programming, you can still make simple automated tests with it.

48

참고 답변

When evaluating a CI/CD platform, I look for scalability to handle growing workloads, reliability to ensure consistent performance, seamless integration with our version control system, support for defining complex pipelines, robust security features to protect our code and infrastructure, and comprehensive reporting to track the progress and identify potential issues. These characteristics are essential for building a robust and efficient CI/CD pipeline.

49

참고 답변

Microservices require independent deployment pipelines, more granular tests, and orchestration tools to manage dependencies and communication between services.

50

참고 답변

A CI/CD pipeline is an automated workflow that moves code from development to production. It consists of stages like building, testing, packaging, and deployment.

51

참고 답변

This is probably one of the most common DevOps interview questions out there because by answering it correctly, you show that you actually know what DevOps engineers (A.K.A “you”) are supposed to work on. That said, this is not a trivial question to answer because different companies will likely implement DevOps with their own “flavor” and in their own way. At a high level, the role of a DevOps engineer is to bridge the gap between development and operations teams with the aim of improving the development lifecycle and reducing deployment errors. With that said other key responsibilities may include: Implementing and managing CI/CD pipelines. Automating infrastructure provisioning and configuration using IaC tools. Monitoring and maintaining system performance, security, and availability. Collaborating with developers to streamline code deployments and ensures smooth operations. Managing and optimizing cloud infrastructure. Ensuring system scalability and reliability. Troubleshooting and resolving issues across the development and production environments.

52

참고 답변

Benefits include faster time to market, reduced risk, improved quality, better collaboration, and continuous feedback.

53

참고 답변

Integrating third-party services into a CI/CD pipeline often involves using APIs or plugins that the CI/CD tools support. Most CI/CD platforms, like Jenkins, GitLab CI, or CircleCI, have built-in or community-supported plugins for popular third-party services such as Slack, Jira, or AWS. For instance, you might use a Slack plugin to send notifications to your team about the build status or use an AWS plugin to deploy your application directly to EC2 or S3. In addition, you typically need to configure authentication and permissions. This might involve generating API tokens or using service principals and securely storing these credentials in the CI/CD pipeline environment variables or secret management tools like HashiCorp Vault. The actual integration steps will vary depending on the third-party service and the CI/CD tool, but it generally boils down to installing the necessary plugins or using APIs, followed by configuring the required credentials and permissions.

54

참고 답변

55

참고 답변

Secrets are sensitive data such as passwords and tokens. CI/CD tools store them securely using encrypted secret managers.

56

참고 답변

Version control is a system that tracks changes to code over time, allowing teams to collaborate, revert to previous versions, and maintain a history of modifications. It ensures that developers can work on different features simultaneously without overwriting each other's changes. Git is the most widely used distributed version control system, enabling multiple developers to work on the same project while maintaining a full history of changes. Key Git features relevant to DevOps: - Branching & Merging – Developers can create separate branches to work on features and merge them once completed - Distributed Nature – Every developer has a full copy of the repository, allowing offline work - Integration with CI/CD – Git is essential for automating CI/CD pipelines, triggering builds and tests on every code commit Why it matters Version control is fundamental to DevOps workflows. Interviewers ask this question to test if you understand how Git enables collaboration and automation in modern development. For example A team using GitHub and Jenkins can set up a CI/CD pipeline that automatically triggers tests and deployments every time new code is pushed to the main branch. This reduces manual effort and ensures faster, more reliable releases.

57

참고 답변

Version control is basically a system that tracks changes to files over time, so you can always go back to a specific version if needed. In my experience, using version control has been critical for collaborating with other developers and understanding the history of our codebase. We've used it extensively to manage features, bug fixes, and releases, which is a fundamental aspect of building a robust CI/CD pipeline.

58

참고 답변

- API Server: Access point - etcd: Maintains cluster state - kubelet: Communicates with the node - Controller Manager: Loops of Reconciliation - Scheduler: Allocates pods to nodes

59

참고 답변

In today's digitized world, organizations must reinvent their product deployment systems to be more robust and flexible in order to keep up with the competition. This is where the DevOps concept comes into the picture. DevOps plays a crucial part in generating mobility and agility to the entire software development pipeline, from idea to deployment and to the end-users. DevOps is the solution that drives a more streamlined and efficient process of continuously updating and improving products.

60

참고 답변

DevOps is more of an organizational and cultural approach that promotes collaboration and communication between both the engineering and operation teams. Meanwhile, continuous delivery is an essential factor that contributes to the success of implementing DevOps into the product development workflow. Continuous delivery practices help to make new releases more reliable and establish a more seamless and shorter process. The key purpose of DevOps is to effectively combine the Dev and Ops roles, remove all silos, and deliver business goals independent of continuous delivery practices. Alternatively, continuous delivery works best when there is already a DevOps process in place. Thus, it amplifies collaboration and streamlines the unified product development cycle of the organization.

61

참고 답변

Continuous Integration (CI), Continuous Delivery (CD), and Continuous Deployment are practices in DevOps that aim to streamline the software release process. CI involves frequently integrating code changes into a shared repository and running automated builds and tests. This practice helps me catch integration issues early, ensuring the codebase is always in a working state. In CI, my goal is not to deploy directly but to validate changes continuously. With Continuous Delivery, I extend CI by automating the process of preparing code for release. Although deployment to production isn't automatic, I always have a deployable build ready. Continuous Deployment goes a step further by automatically deploying every successful build to production, eliminating the need for manual releases. This approach ensures my code reaches users instantly, provided it passes all tests, maximizing deployment speed and responsiveness. Each method builds on the previous one, creating a seamless pipeline from development to production. For Continuous Integration (CI), I often set up a pipeline to run tests on every commit. In contrast, Continuous Delivery (CD) requires staging configurations, as shown in this Jenkinsfile example: pipeline { agent any stages { stage('Build') { steps { echo 'Building...' } } stage('Test') { steps { echo 'Running Tests...' } } stage('Staging') { steps { echo 'Deploying to staging...' } } } } Continuous Deployment would add a Production stage to deploy automatically to live servers. This distinction between CD and Continuous Deployment ensures each stage has been tested, so production remains stable and reliable.

62

참고 답변

In the context of continuous integration, branches should follow trunk-based development practices and thus be short-lived. Ideally, a branch should last for a few hours or, at most, a day.

63

참고 답변

Usually working with Prometheus, Elasticsearch, or Loki, it shows time series data using dashboards.

64

참고 답변

A build pipeline is an automated process that compiles, tests, and prepares code for deployment. It typically involves multiple stages, such as source code retrieval, code compilation, running unit tests, performing static code analysis, creating build artifacts, and deploying to one of the available environments. The build pipeline effectively removes humans from the deployment process as much as possible, clearly reducing the chance of human error. This, in turn, ensures consistency and reliability in software builds and speeds up the development and deployment process.

65

참고 답변

Deployment failures often point to environment-related issues rather than code problems. Possible causes and solutions: - Configuration errors: Verify environment variables, credentials, and configuration files. - Network or DNS issues: Ensure target servers are reachable. - Infrastructure drift: Use tools like Terraform or Ansible to maintain consistency. - Incorrect scripts: Review deployment scripts or YAML pipelines for syntax errors. By walking the interviewer through this troubleshooting flow, you show your understanding of both infrastructure as code and automation in DevOps.

66

참고 답변

Security in DevOps (often called DevSecOps) ensures that security is integrated throughout the software development lifecycle (SDLC) rather than being an afterthought. Best practices for securing a DevOps pipeline: - Use Secrets Management – Store sensitive credentials in HashiCorp Vault, AWS Secrets Manager, or Kubernetes Secrets, never in code - Implement Role-Based Access Control (RBAC) – Restrict permissions using least privilege access to CI/CD tools and cloud resources - Enable Code Scanning & Dependency Checks – Use SonarQube, Snyk, or OWASP Dependency-Check to detect vulnerabilities in code and dependencies - Automate Security Testing – Integrate Static (SAST), Dynamic (DAST), and Infrastructure (IAST) security testing into CI/CD pipelines - Sign and Verify Artifacts – Use Sigstore or Cosign to sign and verify container images before deployment - Monitor and Audit Logs – Use SIEM tools like Splunk, ELK Stack, or Datadog to track pipeline activity and detect suspicious behavior Why it matters Interviewers ask this to test whether you understand how to integrate security into DevOps. A secure pipeline prevents data leaks, unauthorized access, and software supply chain attacks. For example A team deploying containers in AWS EKS can enforce image signing policies, use AWS Secrets Manager for credentials, and integrate Snyk for vulnerability scanning—ensuring a secure, automated CI/CD workflow.

67

참고 답변

Docker is an open-source platform that enables developers to create, deploy, and run applications within lightweight, portable containers. These containers package an application along with all of its dependencies, libraries, and configuration files. That, in turn, ensures that the application can run consistently across various computing environments. Docker has become one of the most popular DevOps tools because it provides a consistent and isolated environment for development, continuous testing, and deployment. This consistency helps to eliminate the common "It works on my machine" problem by ensuring that the application behaves the same way, regardless of where it is run—whether on a developer's local machine, a testing server, or in production. Additionally, Docker simplifies the management of complex applications by allowing developers to break them down into smaller, manageable microservices, each running in its own container. This approach not only supports but also enhances scalability, and flexibility and it makes it easier to manage dependencies, version control, and updates.

68

참고 답변

- Continuous Delivery requires manual approval before pushing to production. - Continuous Deployment automatically releases every code change that passes tests. ✅ Use case tip: Some industries (e.g., healthcare or finance) prefer Continuous Delivery due to compliance requirements.

69

참고 답변

In my experience, building artifacts is a critical step in the CI/CD pipeline. An artifact refers to a by-product of the build process, which could be a packaged application or a compiled binary that you intend to deploy, or it could be log files, test results, or reports generated during the process. My encounter with building artifacts has been primarily using tools like Jenkins or GitLab CI. Usually, after the code is pulled from the version control system, the build phase of the pipeline kicks off and compiles the code into executable code, which then results in the creation of an artifact. This artifact is then stored in an artifact repository like JFrog Artifactory or Nexus Repository which acts like a version control system for these binaries. We can track each build with its unique version number aiding in quick rollbacks if needed and also ensuring exactly the same artifact is promoted through each stage, adding consistency to the CI/CD pipeline. An integral part of this process is to ensure useless or obsolete artifacts are cleaned regularly to avoid unnecessary clutter and saving storage space, which tools like Jenkins support via plugins. Overall, my experience with creating and managing build artifacts has been fundamental in ensuring robust, repeatable processes in the CI/CD pipeline.

70

참고 답변

- Store secrets safely in secret stores like Azure Key Vault or AWS Secrets Manager. - Add secrets as environmental variables - Steer clear of recording private information - Periodically change tokens and keys

71

참고 답변

Git prune is a command that deletes all the files that are not reachable from the current branch. The prune command is useful when you have a lot of files in your working directory that you don't want to keep. The primary use of git prune is to clean up your working directory after you have finished working on a project. What actually git prune does is, suppose you have an object or commit that is no longer reachable from the current branch. Command: git fetch –prune

72

참고 답변

To maintain a healthy and efficient CI/CD pipeline, start with keeping your builds fast; this often means optimizing your codebase and parallelizing tests. Frequent but small commits can help ensure that changes integrate smoothly and issues are caught early when they're easier to fix. Automating as much as possible, including testing and deployment, can reduce human error and increase consistency. It's also essential to have a good monitoring and alerting system in place to quickly catch and address any issues in your pipeline. Clear and detailed documentation can help both current team members and new hires understand the pipeline's workflow and nuances, reducing downtime when problems occur. Finally, regularly review and refine your pipeline. Technology and requirements change, so your CI/CD pipeline should evolve alongside those changes to stay optimal.

73

참고 답변

We: - Write automated tests - Define quality gates - Monitor pipeline stability - Collaborate with DevOps on failure handling

74

참고 답변

Long-running pipelines slow feedback, reduce deployment frequency, and frustrate developers. They can lead to timeouts, resource contention, and lower team efficiency. To address this, break pipelines into smaller stages, run tasks in parallel, and isolate flaky tests. Use caching and incremental builds to avoid unnecessary work. Nightly or asynchronous tasks can be separated from critical build paths. Regularly reviewing build performance metrics helps identify bottlenecks. Keeping pipelines fast and reliable encourages adoption and trust in the automation process.

75

참고 답변

There's no fixed number of tests that a project should have, but the goal is to cover critical code paths and edge cases to ensure high confidence in our releases. We focus on writing tests that provide meaningful coverage and detect potential issues early in the development process. It's about quality over quantity.

76

참고 답변

Docker plays a significant role in CI/CD processes by providing a consistent and efficient environment for developing, testing, and deploying applications. 1. Consistency Across Environments – Docker enables the creation of containerized environments that are consistent across different stages of the CI/CD pipeline. 2. Efficiency – Docker containers are lightweight and can be quickly started, stopped, or replicated, which speeds up the testing and deployment processes. This efficiency is crucial for rapid iterations in a CI/CD pipeline. 3. Automation and Integration – Docker easily integrates with various CI/CD tools and platforms like Jenkins, GitLab CI, and AWS CodePipeline. This allows automated builds, tests, and deployments to be carried out within containers, streamlining the entire process. 4. Simplified Setup and Configuration – With Docker, you can define the entire environment setup in a single Dockerfile, which automates the creation of the development and deployment environments. This reduces setup time and configuration errors. 5. Scalability – Docker supports horizontal scaling by allowing you to deploy multiple instances of an application component across different containers. This helps manage increased load and optimize resource usage. 6. Version Control for Environments – Docker images can be version-controlled, allowing you to track changes to application environments, roll back to previous versions, and maintain a history of environment configurations 7. Resource Optimization – Docker helps in optimizing resource utilization by sharing the host operating system's kernel and reducing the need for duplicating system libraries and files, which is a common issue in full-fledged virtual machines.

77

참고 답변

The 7 Cs of DevOps are: - Continuous Integration: Regularly merging code changes into a shared repository. - Continuous Testing: Automatically running tests to ensure code quality. - Continuous Delivery: Ensuring code is always in a deployable state. - Continuous Deployment: Automatically deploying code to production. - Continuous Monitoring: Tracking system performance and issues in real-time. - Continuous Feedback: Gathering and responding to user and system feedback. - Continuous Operations: Maintaining system stability and uptime through automated processes.

78

참고 답변

To monitor pipeline health, I implement real-time dashboards that track metrics like pipeline duration, success rate, queue time, and test pass percentage, using tools like Prometheus and Grafana. Alerting is implemented for pipeline failures, stage timeouts, and flaky test thresholds, with notifications sent to Slack or email, and I set up automated incident response for critical failures like deployment rollbacks or security scan breaches.

79

참고 답변

Infrastructure as Code (IaC) is the practice of provisioning and managing cloud infrastructure using machine-readable configuration files rather than clicking through manual web consoles. Tools like Terraform allow you to define networks, servers, and databases in code. In a CI/CD pipeline, the IaC script is executed before the application deployment step. This ensures that the pipeline automatically provisions the exact, pristine server environment required for the application to run, effectively treating infrastructure changes with the same rigorous testing as software changes.

80

참고 답변

Continuous delivery (CD) is a software development practice that aims to automate the entire software delivery process, from code commit to deployment. The goal of CD is to make it possible to release software to production at any time by ensuring that the software is always in a releasable state.

81

참고 답변

Continuous delivery (CD), together with CI makes a complete flow for deliverable code packages. In this phase, automated building tools are applied to compile artifacts (e.g., source code, test scripts, configuration files, and environments) and have them ready to be delivered to the end user. With that in mind, in a CD environment, new releases are just one click away from being published with fully functional features and minimal human intervention.

82

참고 답변

We use several deployment strategies depending on the application and the risk tolerance. Some common strategies include Blue-Green deployments, where we switch traffic between two identical environments; Canary releases, where we roll out changes to a small subset of users; Rolling deployments, where we gradually update instances; Recreate deployments, where we shut down the old version before deploying the new one; and A/B testing, where we compare different versions of a feature to see which performs better.

83

참고 답변

Infrastructure as Code (IaC) is a method of managing and provisioning IT infrastructure using code, rather than manual configuration. It allows teams to automate the setup and management of their infrastructure, making it more efficient and consistent. This is particularly useful in the DevOps environment, where teams are constantly updating and deploying software. Instead of clicking through dashboards or configuring systems by hand, you define the desired infrastructure in code files (using tools like Terraform, Ansible, or CloudFormation). These files can then be version-controlled, reused, tested, and automated—just like application code. IAC Benefits are: - Consistency: Same configuration every time, reducing errors. - Automation: Fast setup and tear-down of environments. - Scalability: Easily scale infrastructure up or down with code. - Versioning: Track and roll back changes using Git or other version control.

84

참고 답변

Automated testing runs test scripts automatically during the pipeline. It ensures new changes do not break existing functionality.

85

참고 답변

A container is a runtime instance of a container image (which is a lightweight, executable package that includes everything needed to run your code). It is the execution environment that runs the application or service defined by the container image. When a container is started, it becomes an isolated process on the host machine with its own filesystem, network interfaces, and other resources. Containers share the host operating system's kernel, making them more efficient and quicker to start than virtual machines. A virtual machine (VM), on the other hand, is an emulation of a physical computer. Each VM runs a full operating system and has virtualized hardware, which makes them more resource-intensive and slower to start compared to containers.

86

참고 답변

To achieve zero-downtime deployments, strategies like canary releases and rolling updates are used. Blue/Green Deployment is a method where you maintain two identical production environments, with only one active at a time. Updates are deployed to the inactive "blue" environment, then traffic is switched to it, ensuring seamless transitions and mitigating downtime.

87

참고 답변

The banker's algorithm is a resource allocation and deadlock avoidance algorithm that tests for safety by simulating the allocation for the predetermined maximum possible amounts of all resources, then makes an “s-state” check to test for possible activities, before deciding whether allocation should be allowed to continue.

88

참고 답변

Self-hosted runners are custom machines for executing CI/CD jobs instead of cloud-hosted ones. - Example: GitHub Actions supports Linux, Windows, macOS runners.

89

참고 답변

Feature flags (or feature toggles) allow you to decouple code deployment from feature release. You can deploy new, incomplete code to production behind a disabled flag. This allows for continuous integration to the main branch without affecting users. They enable **progressive delivery** by allowing you to turn the feature on for specific user segments (e.g., internal testers, beta users, or a percentage of all users) directly in production. This provides fine-grained control over a release, allows for testing in a real-world environment, and provides an instant “kill switch” to disable a faulty feature without needing to redeploy.

90

참고 답변

The lifespan of a branch in version control depends on the workflow and purpose. Short-lived branches, like feature branches, are generally preferred in CI/CD because they allow developers to integrate changes quickly, reducing the risk of conflicts and making merging easier. Trunk-based development, for instance, encourages branches to live only for a few days before merging to keep the mainline stable and updated. Factors such as the project's complexity, team size, and release cycle can also impact branch lifespan. In larger projects, branches may live longer to accommodate feature development or bug fixes, but in CI/CD environments, shorter-lived branches are ideal for continuous testing and integration, ensuring the codebase remains stable and deployable at all times.

91

참고 답변

The banker's algorithm is a resource allocation and deadlock avoidance algorithm that tests for safety by simulating the allocation for the predetermined maximum possible amounts of all resources, then makes an “s-state” check to test for possible activities, before deciding whether allocation should be allowed to continue.

92

참고 답변

Isolated from the host and other containers, a lightweight, portable device runs applications with all dependencies.

93

참고 답변

A model where Git is the single source of truth, and agents like ArgoCD or Flux reconcile infrastructure automatically from version controlled manifests.

94

참고 답변

DevSecOps adds security to CI/CD by including: Static code analysis Dependency scanning Container image scanning Policy enforcement Security becomes automated and continuous.

95

참고 답변

As far as CI/CD goes, it does not require any programming language or scripting language to be used. It is not necessary to use any programming or scripting language when you use a GUI-based tool like Azure DevOps (ADO). The use of ARM templates in Azure DevOps requires scripting knowledge. Therefore, it depends on the tools and different ways of setting up CI/CD.

96

참고 답변

- Lead Time: Time from commit to deployment. - Mean Time to Recovery (MTTR): Time to recover from failures.

97

참고 답변

With continuous deployment, developers can focus solely on the product because their final task in the pipeline is to review pull requests and merge them to the master branch. This method enables frictionless deployment and shortens the deployment duration by releasing new features and fixes right after they have passed the automated tests. Customers are the ones to evaluate the quality of each release. Bug fixes for new releases are easier to handle because each release is delivered in small batches.

98

참고 답변

Canary deployment releases a new version to a small subset of users first. If the deployment works correctly, it gradually rolls out to all users.

99

참고 답변

GitOps uses Git repositories as the source of truth for infrastructure and deployments. Changes are applied automatically through pipelines.

100

참고 답변

Rollback mechanisms in Continuous Deployment (CD) are crucial for reverting to a previous version of an application when issues are detected in the current version. Here's how rollback mechanisms are typically implemented: 1. Automated Rollback Scripts: CD pipelines often include automated rollback scripts or procedures that can be triggered when issues are detected. These scripts are designed to reverse the deployment by redeploying the previous version of the application. 2. Version Tagging: Each deployment in CD is versioned and tagged, making it easy to identify and switch back to a specific, known-working version if problems arise. 3. Traffic Routing: Load balancers and routing mechanisms can be configured to quickly switch traffic back to the previous version of the application in case of issues with the new version. 4. Database Rollback: If database schema changes are part of the deployment, database rollback scripts can be used to revert the schema to its previous state. 5. Monitoring and Alerts: Continuous monitoring in production environments is essential for quickly detecting issues. When problems are detected, alerts are triggered to notify the operations team, who can then initiate the rollback process. 6. Testing in Isolation: Before deploying to the entire production environment, new versions are often tested in isolation (e.g., staging or a canary release). If issues are detected during testing, the deployment to the wider audience is halted or rolled back. 7. Post-Mortem Analysis: After a rollback, a post-mortem analysis is typically conducted to understand the root cause of the issue. This analysis helps prevent similar problems in future deployments.

101

참고 답변

A runner or agent executes pipeline jobs on a machine. For example, GitLab CI/CD uses GitLab runners.

102

참고 답변

I handle flaky tests by first isolating and quarantining them in a separate pipeline stage to avoid blocking main builds, then analyzing failure patterns using test retries and logging to identify root causes. I prioritize fixing or removing flaky tests, implement test stability metrics, and use automated re-run policies for transient failures while maintaining a dashboard to track test reliability over time.

103

참고 답변

Azure DevOps ensures secure collaboration through several mechanisms, including: - - Role-based access control (RBAC): This allows organizations to grant permissions based on roles, ensuring that team members have access only to the resources they need. - Integration with Azure Active Directory (AAD): This provides centralized identity and access management, including multi-factor authentication (MFA) and conditional access policies. - Secure repositories: Azure Repos offer features like branch policies, pull request approvals, and code scanning tools to ensure that only reviewed and approved code is merged into the main branch.

104

참고 답변

- GitFlow: Uses long-lived feature branches, a `develop` branch, and a `main`/`master` branch. It's structured but can lead to large, complex merges and slower feedback loops. In CI/CD, this often results in separate pipelines for feature branches, develop (deploying to staging), and main (deploying to production). - Trunk-Based Development (TBD): All developers commit directly to a single `main` branch (or short-lived feature branches that merge quickly). This approach requires strong automated testing and often uses feature flags to manage releases. It enables much faster integration and deployment cycles, aligning perfectly with true continuous delivery. The CI/CD pipeline is simpler, focused on validating and deploying the `main` branch rapidly. TBD is generally preferred for teams practicing mature CI/CD as it maximizes feedback speed and reduces merge complexity.

105

참고 답변

End-to-end tests verify full system workflows by simulating user interactions from start to finish, ensuring that all components work together correctly. Acceptance tests, on the other hand, validate that the system meets business requirements and user needs, often involving stakeholders in the testing process. End-to-end tests focus on technical integration, while acceptance tests focus on business value.

106

참고 답변

Continuous Delivery (CD) and Continuous Deployment (CD) are closely related but differ in their final stages: - Continuous Delivery (CD): In CD, every code change that passes automated testing is automatically prepared for deployment to the production environment. However, the actual deployment to production requires manual approval. This means that the code is always in a deployable state but doesn't go to production automatically. - Continuous Deployment (CD): In CD, every code change that passes automated testing is automatically deployed to the production environment without requiring manual approval. This means that changes are continuously and automatically pushed to production as soon as they are verified.

107

참고 답변

I would configure CI/CD by using infrastructure as code (e.g., Terraform) to define cloud-agnostic resources and parameterizing regions and cloud providers as variables. The pipeline would use conditional stages to deploy to each target, with parallel execution across regions, and integrate cloud-specific authentication via secrets management. A central orchestrator would manage state and coordination, while health checks and rollback mechanisms ensure consistency across environments.

108

참고 답변

Monitor using CI/CD tool dashboards, custom monitoring scripts, log analysis, and alerting systems to detect failures or performance issues.

109

참고 답변

- Faster releases: Automating testing and deployment reduces release cycles. - Early bug detection: Issues are caught at the CI stage rather than later in production. - Better collaboration: Developers integrate code frequently, avoiding conflicts. - Consistent environments: Automated builds and tests reduce discrepancies between development and production.

110

참고 답변

Managing dependencies ensures consistent builds. - Solutions: - Use lock files (package-lock.json, Pipfile.lock). - Cache dependencies (npm ci, pip freeze). - Example: - uses: actions/cache@v3 with: path: ~/.npm key: node-${{ hashFiles('**/package-lock.json') }}

111

참고 답변

I monitor pipeline health by collecting metrics on build duration, success rate, queue time, and failure frequency using tools like Prometheus, Grafana, or built-in CI/CD dashboards. Alerting is implemented for critical events such as pipeline failures, significant performance degradation, security scan violations, and secrets expiry, with notifications sent to Slack or PagerDuty. I also set up trend alerts to detect flaky tests or infrastructure issues before they escalate.

112

참고 답변

| HTTP | HTTPS | |---|---| | HTTP does not use data hashtags to secure data. | While HTTPS will have the data before sending it and return it to its original state on the receiver side. | | In HTTP Data is transfer in plaintext. | In HTTPS Data transfer in ciphertext. | | HTTP does not require any certificates. | HTTPS needs SSL Certificates. | | HTTP does not improve search ranking | HTTPS helps to improve search ranking |

113

참고 답변

CI/CD is described as a set of practices and tools that the development and operations teams use to automate and streamline their development and deployment processes.

114

참고 답변

Rolling back is essential for minimizing downtime and user impact. Rollback strategies include: - Blue-Green Deployment: Maintain two environments (Blue and Green). Roll traffic back to the stable one if the new deployment fails. - Canary Deployment: Gradually release changes to a subset of users before full rollout. - Versioned Artifacts: Store build artifacts in a repository (like Nexus or JFrog) for easy re-deployment of previous versions. Mentioning these strategies during an interview demonstrates practical experience in deployment automation examples and real-world CI/CD management.

115

참고 답변

A CI/CD Engineer is responsible for building, managing, and optimizing CI/CD pipelines, ensuring that code moves smoothly from development to production. This role requires a deep understanding of automation tools, such as Jenkins, GitLab CI, or CircleCI, as well as experience in integrating version control and testing frameworks. CI/CD Engineers often work with multiple stakeholders, including developers, QA, and operations teams, to streamline deployments and minimize disruptions. Key skills for a CI/CD Engineer include scripting languages like Python or Bash, proficiency with containerization tools like Docker, and knowledge of configuration management tools like Ansible or Terraform. Strong problem-solving abilities and a deep understanding of DevOps principles are also essential. These skills enable CI/CD Engineers to automate complex workflows, reduce deployment time, and improve the reliability of the release process.

116

참고 답변

Feature flags allow code to be deployed without immediately enabling new functionality. They provide the ability to toggle features on or off at runtime, enabling safer deployments, A/B testing, and quick rollback without redeploying. Feature flags decouple deployment from release, offering greater control over production behavior.

117

참고 답변

To secure CI/CD, follow these best practices: ✅ Use Secret Management: Store secrets in Vault, AWS Secrets Manager, or Kubernetes Secrets. ✅ Enable Role-Based Access Control (RBAC): Restrict who can trigger deployments. ✅ Enforce Code Signing: Sign artifacts to ensure they are not tampered with. ✅ Run Security Scans: Use SAST, DAST, and dependency scanning tools. ✅ Monitor CI/CD Pipelines: Detect suspicious activity using SIEM tools like Splunk or Datadog.

118

참고 답변

The correct answer is ‘c'. Continuous integration should be used to immediately test any changes to the code.

119

참고 답변

Pipeline as Code is the practice of defining your CI/CD pipeline's configuration in a version-controlled file (e.g., a `Jenkinsfile`, `.gitlab-ci.yml`, or `azure-pipelines.yml`) that lives alongside your application code. Benefits: - Version Control: The pipeline is versioned, auditable, and can be reviewed in pull requests just like any other code. - Reproducibility: You can easily recreate a pipeline and track its history. - Collaboration: All team members can see and contribute to the pipeline's definition. - Automation: It enables fully automated setup and management of build and deployment processes.

120

참고 답변

‘C' is the right answer to this question. Information gathering is not a feature of the CD.

121

참고 답변

Infrastructure is never manipulated by hand after being deployed. From thenceforth, any change will create a new instance which enhances consistency and rollback reliability.

122

참고 답변

- Jenkins: Open-source, widely used, highly customizable but requires maintenance. - GitLab CI/CD: Integrated with GitLab repositories, simpler setup, great for DevOps workflows. - GitHub Actions: Works well with GitHub projects, supports YAML-based workflows. - CircleCI: Cloud-based, optimized for speed and ease of use. - Azure DevOps: Microsoft's CI/CD tool with deep integration into Azure services.

123

참고 답변

A Jenkins file is a text file that contains a pipeline's configuration. It outlines the pipeline's stages, such as build, test, and deployment, as well as the actions that must be taken at each one. Example of a Jenkins File: pipeline { agent any stages { stage('Test') { steps { bat "mvn -D clean test" } post { // If Maven was able to run the tests, even if some of the test // failed, record the test results and archive the jar file. success { publishHTML([ allowMissing: false, alwaysLinkToLastBuild: false, keepAll: false, reportDir: 'target/surefire-reports/', reportFiles: 'emailable-report.html', reportName: 'HTML Report', reportTitles: '', useWrapperFileDirectly: true]) } } } } }

124

참고 답변

- Cloud-managed Runners (e.g., GitHub-hosted runners): Maintained by the CI/CD provider. They are simple to use and provide a clean, ephemeral environment for every job. The downside is that they can be more expensive and offer less customization. - Self-hosted Runners: You manage the virtual machines or containers that run the CI jobs. This provides full control over the hardware, operating system, and installed software. It can be more cost-effective and is necessary when your jobs need access to resources in a private network. However, it adds operational overhead for maintenance and security.

125

참고 답변

A Git branch is an independent line of development, allowing developers to work on different features or fixes without affecting the main codebase. Branches are crucial in collaborative coding, as they enable developers to work concurrently on various tasks while maintaining the stability of the mainline code. For example, a developer can create a new branch for a feature, make all necessary changes, and merge it back into the main branch once testing is complete. Branches allow for organized and isolated work, making it easier to manage feature development and bug fixes in complex projects. In CI/CD, branches help manage the flow of code through various stages of development, testing, and deployment, promoting collaboration and code quality while reducing the risk of disruptions in production.

126

참고 답변

A successful workflow when implementing continuous integration encompasses the following practices: - Implement and maintain a repository for the project's source code - Automate the build and integration - Make the build self-testing - Commit changes daily to the baseline - Build all commits added to the baseline - Keep the builds fast - Run tests in a clone of the production environment - Make it easy to get the latest deliverables - Make build results easy to be monitored by everyone - Automate deployment

127

참고 답변

- Prometheus: Metrics collection - Grafana: Dashboards - ELK/EFK stack: Log aggregation - Datadog: SaaS for full stack monitoring

128

참고 답변

Monitoring and logging are crucial in CI/CD pipelines because they provide visibility into the performance and health of your automated processes. Monitoring helps track the behavior of builds, tests, and deployments in real-time, allowing you to quickly detect and respond to issues like failed deployments or performance bottlenecks. Logging, on the other hand, keeps a detailed record of these activities, which is invaluable for diagnosing problems, auditing changes, and understanding trends over time. By using monitoring tools, you can set up alerts to notify you of critical issues, ensuring that your team can address problems before they impact users. Logging complements this by providing the granular details needed to troubleshoot those issues effectively. Together, they enhance the reliability, maintainability, and overall efficiency of your CI/CD pipeline.

129

참고 답변

GitOps treats Git as the canonical source of truth for deployments. CI tool will produce an artifact, for CDs it is these tools that continually sync your production to the state defined in Git.

130

참고 답변

I would implement secrets management by integrating a dedicated secrets manager such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault with the CI/CD pipeline. Secrets are stored encrypted and accessed via environment variables or direct API calls at runtime, avoiding hardcoding or storing them in repository files. I would also use role-based access controls, rotate secrets regularly, and audit access logs to ensure security.

131

참고 답변

- Automation with Playbooks: Ansible uses playbooks (YAML files) to define deployment tasks. In a CI/CD pipeline, Ansible can be used to automate the deployment of applications across multiple environments (e.g., development, staging, production). - Environment Management: In the CI/CD pipeline, you can dynamically specify the target environment by defining different inventory files for each environment. This allows Ansible to deploy to different servers or clusters depending on the environment. - Trigger from Pipeline: Ansible can be triggered by CI/CD tools like Jenkins or GitHub Actions. The pipeline can run specific Ansible playbooks that deploy the application, configure the system, and perform other necessary tasks for the environment.

132

참고 답변

Manual triggers require human intervention to start a pipeline process, often used for production deployments or critical environments where approvals are needed. Automated triggers are initiated automatically upon events like code commits, merges, or tag creations. Most modern CI/CD pipelines use automated triggers to streamline continuous integration while preserving manual triggers for controlled releases.

133

참고 답변

Chaos Engineering involves intentionally injecting failures to test system resilience. - Example tools: - Gremlin, LitmusChaos (Kubernetes-based). - AWS Fault Injection Simulator (FIS). - In CI/CD Pipelines: - Add a chaos test stage before production deployment. - Example: steps: - name: Run Chaos Test run: gremlin attack --target kubernetes --cpu 90%

134

참고 답변

Secrets such as passwords, tokens, and keys should never be hardcoded. Instead, use secret management tools like HashiCorp Vault, AWS Secrets Manager, or CI/CD tool integrations (e.g., GitHub Actions Secrets or GitLab CI variables). These allow secure, encrypted handling of sensitive data during pipeline execution.

135

참고 답변

Canary deployment is a release strategy where new code is deployed to a small subset of users or systems first. If no issues are reported, the deployment gradually rolls out to the rest. In CI/CD, it can be implemented with orchestration tools like Kubernetes or service meshes like Istio, allowing controlled, low-risk production releases.

136

참고 답변

I design pipelines to meet compliance and auditing requirements by integrating mandatory approval gates for production deployments, logging all pipeline actions with timestamps and user identities, and generating immutable deployment records in a secure database. Pipelines include automated compliance checks, such as license scanning and security policy validation, and produce audit trails that link each deployment to a specific artifact version, commit hash, and approver, ensuring full traceability.

137

참고 답변

- Schedule unused resources for shutdown - Implement spot instances and autoscaling - Track spending using resources such AWS Cost Explorer - Automate dev/test environment cleanup

138

참고 답변

Security measures include access control, vulnerability scanning, and continuous monitoring of the pipeline.

139

참고 답변

DevSecOps is the practice of integrating security testing and practices into every phase of the software development and deployment lifecycle, rather than treating it as a final step. Integration into a pipeline would look like this: - SAST (Static Application Security Testing): Integrated early in the CI process, often as a step after code is checked out. It scans the raw source code for potential vulnerabilities (e.g., SQL injection flaws, hardcoded secrets). Tools include SonarQube, Checkmarx. - SCA (Software Composition Analysis): Runs after dependencies are installed. It scans all open-source libraries and their transitive dependencies for known CVEs (Common Vulnerabilities and Exposures). Tools include Snyk, OWASP Dependency-Check. - DAST (Dynamic Application Security Testing): Runs later in the pipeline, against a running application in a staging or test environment. It probes the application from the outside, simulating attacks to find runtime vulnerabilities like XSS. Tools include OWASP ZAP, Veracode.

140

참고 답변

I always make sure: - Unit tests run after every commit - Integration tests kick in post-build - Functional UI tests run in parallel on staging - Failures instantly notify Slack/Teams

141

참고 답변

By using semantic versioning, maintaining a changelog, and integrating version control systems like Git.

142

참고 답변

- EC2: Compute - S3: Artifact and log storage - EKS: Kubernetes - CI/CD: CodePipeline/CodeBuild - IAM: Access control - CloudWatch: Monitoring

143

참고 답변

- Checkout from Git - Build or compile - Test (unit, integration, E2E) - Storage of artifacts - Install to production/staging - Track outcomes and rollbacks

144

참고 답변

Feature flags enable developers to toggle features without deploying new code. They help test new functionality safely in production.

145

참고 답변

Shift-left testing means moving testing earlier in the development cycle to catch defects sooner. It fits into CI/CD by: - Running unit and integration tests in CI instead of waiting for QA. - Using automated security and performance testing before deployment. - Encouraging developers to write tests early in the process.

146

참고 답변

To optimize a Docker container for performance, you need to focus on reducing image size, improving resource efficiency, and minimizing startup time. Here are key strategies: - Use a Lightweight Base Image: Instead of ubuntu ordebian , use smaller images likealpine orscratch to reduce the container size and improve speed. - Minimize Layers in Dockerfile: Combine multiple RUN commands using&& to reduce the number of image layers, making the container more efficient. - Use Multi-Stage Builds: Build applications in one stage and copy only the necessary files to the final image, reducing bloat. - Optimize Dependencies: Remove unnecessary libraries, packages, and tools that are not required for production. - Enable Docker Caching: Structure the Dockerfile in a way that rarely changing layers come first, so Docker can reuse cached layers instead of rebuilding everything.

147

참고 답변

The build stage is the first stage in a CI/CD pipeline where the source code is compiled and packaged into an executable format. This step ensures that the code is error-free, compiles correctly, and is ready for testing and deployment. The build process often includes pulling dependencies, compiling code, and creating artifacts, such as Docker images or JAR files. For example, a simple Maven build command might look like this: mvn clean install The importance of the build stage cannot be overstated, as it lays the groundwork for testing and deployment. If the build fails, the pipeline halts, preventing buggy or incompatible code from progressing to later stages. By catching issues early in the process, the build stage saves valuable time and resources, ensuring that only reliable, functional code moves forward in the CI/CD pipeline.

148

참고 답변

Identify the cause of the bottleneck, optimize the slow steps, parallelize tasks, and consider scaling resources.

149

참고 답변

To implement security in a DevOps pipeline (DevSecOps), you should integrate security practices throughout the development and deployment process. This is not just about securing the app once it's in production, this is about securing the entire application-creation process. That includes: Shift Left Security: Incorporate security early in the development process by integrating security checks in the CI/CD pipeline. This means performing static code analysis, dependency scanning, and secret detection during the build phase. Automated Testing: Implement automated security tests, such as vulnerability scans and dynamic application security testing (DAST), to identify potential security issues before they reach production. Continuous Monitoring: Monitor the pipeline and the deployed applications for security incidents using tools like Prometheus, Grafana, and specialized security monitoring tools. Infrastructure as Code - Security: Ensure that infrastructure configurations defined in code are secure by scanning IaC templates (like Terraform) for misconfigurations and vulnerabilities (like hardcoded passwords). Access Control: Implement strict access controls, using something like role-based access control (RBAC) or ABAC (attribute-based access control) and enforcing the principle of least privilege across the pipeline. Compliance Checks: Figure out the compliance requirements and regulations of your industry and integrate those checks to ensure the pipeline adheres to industry standards and regulatory requirements. Incident Response: Figure out a clear incident response plan and integrate security alerts into the pipeline to quickly address potential security breaches.

150

참고 답변

- Check the build logs for detailed error messages. - Verify the test environment configuration. - Rerun the pipeline to rule out temporary issues. - If the failure persists, isolate and fix the issue before merging the branch. You can also automate notifications using Slack or email alerts to inform teams about failures, ensuring faster collaboration and resolution.

151

참고 답변

Integrating CI/CD with Infrastructure as Code (IaC) ensures that infrastructure changes are automated and version-controlled. - Best Practices: - Store IaC scripts (Terraform, Ansible, CloudFormation) in Git. - Use automated testing (e.g., terraform validate, ansible-lint). - Apply changes using CI/CD pipelines (terraform apply). - Example GitHub Actions Pipeline for Terraform: jobs: terraform: steps: - run: terraform init - run: terraform validate - run: terraform apply -auto-approve

152

참고 답변

Git Fetch | Git Pull | |---|---| | Used to fetch all changes from the remote repository to the local repository without merging into the current working directory | Brings the copy of all the changes from a remote repository and merges them into the current working directory | | Repository data is updated in the .git directory | The working directory is updated directly | | Review of commits and changes can be done | Updates the changes to the local repository immediately. | | Command for Git fetch is git fetch | Command for Git Pull is git pull |

153

참고 답변

Common tests include unit tests, integration tests, and end-to-end tests. Security and performance tests may also be included.

154

참고 답변

Executing a DROP COLUMN command on a live database while old application code is still running will cause immediate, catastrophic errors. I handle this using the Expand and Contract pattern, breaking the deployment into multiple backward-compatible pipeline releases. | Phase | Database Action | Application Code Action | |---|---|---| | 1. Expand | Add the new database column. | Deploy code that writes to both the old and new columns, but reads from the old. | | 2. Migrate | Run a background script. | Backfill historical data from the old column into the new one. | | 3. Transition | No database changes. | Deploy code that reads and writes strictly from the new column. | | 4. Contract | Drop the old column. | Clean up old, dead code referencing the dropped column. |

155

참고 답변

Containerization involves packaging an application and its dependencies into a standardized unit called a container, using tools like Docker. Containers provide a consistent environment, ensuring that code runs the same way across different systems. This approach is valuable in DevOps because containers can be easily moved between development, testing, and production environments, reducing compatibility issues. Here's a simple example of creating a Docker container: # Dockerfile for a Node.js app FROM node:14 WORKDIR /app COPY . . RUN npm install CMD ["node", "app.js"] Containerization is relevant in DevOps as it supports efficient scaling, isolation, and faster deployments. With containers, I can rapidly deploy applications, replicate them across environments, and roll back easily if an issue occurs. The portability and isolation provided by containers enhance both the speed and reliability of the CI/CD process.

156

참고 답변

Parallel execution runs multiple jobs simultaneously. This significantly reduces overall pipeline execution time.

157

참고 답변

A Git repository is a storage location for a project's code, allowing developers to track changes and collaborate.

158

참고 답변

DevOps is a combination of development and operations. It is described as a software methodology that consists of different tools that improve communication and collaboration between development and operations teams.

159

참고 답변

A release technique allowing zero downtime deployment and instant rollback by routing traffic between two identical environments.

160

참고 답변

Workstation, server, and node, all are the key components of the chef. So, the correct answer to this CI/CD interview questions is ‘d'.

161

참고 답변

Version control is crucial in DevOps because it allows teams to manage and save code changes and track the evolution of their software systems over time. Some key benefits include collaboration, traceability, reversibility, branching, and release management.

162

참고 답변

Absolutely! Continuous Integration (CI) is all about integrating code changes frequently and automatically testing them to catch issues early. Developers merge their code into a shared repository multiple times a day, and each merge triggers an automated build and test process. Continuous Delivery (CD) takes CI a step further by ensuring that the code is always in a deployable state. Even though the build has passed all tests and is ready for deployment, the actual release to production is still a manual step. This practice ensures that software can be reliably released at any time. Continuous Deployment goes beyond continuous delivery by automating the deployment process itself. Every change that passes all stages of the production pipeline is released to customers automatically, with no human intervention. This allows for very rapid updates and quick feature releases but requires a very mature testing process to avoid issues in production.

163

참고 답변

Jenkins is a popular open-source automation server that facilitates the building, testing, and deployment of code. Some of its key benefits in CI/CD pipelines are: - Automation: Jenkins automates repetitive tasks such as code integration, testing, and deployment. - Scalability: Jenkins can scale to handle large and complex projects with multiple pipelines running concurrently. - Plugins: Jenkins supports a wide range of plugins that integrate with different tools for version control, build tools and deployment processes.

164

참고 답변

As a DevOps engineer, the concept of continuous monitoring should be ingrained in your brain as a must-perform activity. You see, continuous monitoring is the practice of constantly overseeing and analyzing an IT system's performance, security, and compliance in real-time. It involves collecting and assessing data from various parts of the infrastructure to detect issues, security threats, and performance bottlenecks as soon as they occur. The goal is to ensure the system's health, security, and compliance, enabling quick responses to potential problems and maintaining the overall stability and reliability of the environment. Tools like Prometheus, Grafana, Nagios, and Splunk are commonly used for continuous monitoring.

165

참고 답변

Observability is the ability to understand and diagnose the behavior of a complex system, such as a software application, using real-time monitoring and metrics.

166

참고 답변

DevOps Lifecycle is the set of phases that includes DevOps for taking part in Development and Operation group duties for quicker software program delivery. DevOps follows positive techniques that consist of code, building, testing, releasing, deploying, operating, displaying, and planning. DevOps lifecycle follows a range of phases such as non-stop development, non-stop integration, non-stop testing, non-stop monitoring, and non-stop feedback. 7 Cs of DevOps are: - Continuous Development - Continuous Integration - Continuous Testing - Continuous Deployment/Continuous Delivery - Continuous Monitoring - Continuous Feedback - Continuous Operations

167

참고 답변

A rollback strategy is crucial for quickly reverting to a stable version of the application in case of deployment failure. Key elements of a rollback strategy include: - Automation: Rollbacks should be automated to reduce human error and downtime. - Backup Mechanism: Ensure that previous versions of the application are readily available for quick restoration. - Clear Rollback Criteria: Define specific failure criteria to trigger a rollback, such as a failed test or a crash in production.

168

참고 답변

From my own experience: - Early bug detection due to constant testing - Faster feedback loops - Reduced integration issues - Higher confidence in code quality

169

참고 답변

Some popular tools include: - Jenkins - GitLab CI - GitHub Actions - CircleCI - Travis CI - Bamboo - Azure DevOps - TeamCity ? Pro Tip: Be ready to discuss your experience with at least one tool and how it improved your workflow.

170

참고 답변

Pipeline monitoring tracks the health and performance of CI/CD processes. Monitoring tools help detect build failures and deployment issues.

171

참고 답변

Kubernetes is used to deploy and manage containerized applications. CI/CD pipelines often deploy applications directly into Kubernetes clusters.

172

참고 답변

Gitflow is a more structured branching model that uses dedicated branches for features, releases, and hotfixes. In contrast, trunk-based development focuses on merging changes directly into the main branch as frequently as possible. We used Gitflow on a previous project with longer release cycles, but now we prefer trunk-based development because it allows for faster feedback and continuous delivery, which aligns better with our CI/CD goals.

173

참고 답변

Software architectures evolve based on scalability, flexibility, and operational requirements. The three most common architectures in DevOps are monolithic, microservices, and serverless. Monolithic Architecture - A single, tightly coupled application where all components (UI, business logic, database) run as one unit - Simple to develop but hard to scale and deploy independently Microservices Architecture - The application is broken down into small, independent services, each handling a specific function - Easier to scale, deploy, and update individual services without affecting the entire system. - Often deployed using containers and Kubernetes Serverless Architecture - Code runs in event-driven functions that scale automatically (e.g., AWS Lambda, Azure Functions) - No need to manage infrastructure—cloud provider handles provisioning and scaling - Best for highly variable workloads and reducing operational overhead Why it matters Different applications require different architectures based on scale, complexity, and cost. Interviewers ask this to see if you can choose the right architecture for a given use case. For example A legacy banking system might use a monolithic approach, while a real-time streaming service like Netflix would rely on microservices, and a data-processing workflow may be best suited for serverless computing.

174

참고 답변

Docker Compose is, in fact, a tool designed to simplify the definition and management of multi-container Docker applications. It allows you to define, configure, and run multiple containers as a single service using a single YAML file. In a multi-container application, Compose provides the following key roles: Service Definition: With Compose you can specify multiple services inside a single file, you can also define how each service should be built, the networks they should connect to, and the volumes they should use (if any). Orchestration: It manages the startup, shutdown, and scaling of services, ensuring that containers are launched in the correct order based on the defined dependencies. Environment Management: Docker Compose simplifies environment configuration because it lets you set environment variables, networking configurations, and volume mounts in the docker-compose.yml file. Simplified Commands: All of the above can be done with a very simple set of commands you can run directly from the terminal (i.e. docker-compose up, or docker-compose down). In the end, Docker Compose simplifies the development, testing, and deployment of multi-container applications by giving you, as a user, an extremely friendly and powerful interface.

175

참고 답변

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 .

176

참고 답변

Continuous Integration is the process of frequently merging code changes into a shared repository. Each merge triggers automated builds and tests to detect issues early in development.

177

참고 답변

Docker: Uses a background daemon Podman: Daemonless, rootless by default, and more secure for some use cases

178

참고 답변

Serverless allows you to run code without managing servers. Platforms like AWS Lambda or Google Cloud Functions handle provisioning, scaling, and infrastructure making them ideal for event driven tasks.

179

참고 답변

It implies adding security early during development, not at the conclusion. This covers IaC audits, dependency checks, and static code scans.

180

참고 답변

During Continuous Integration, a 'build' refers to the process of transforming source code into a runnable or deployable form. This involves various steps, depending on the nature of the codebase and the target environment. First and foremost, there's compilation for languages that need it. This takes the source code files and converts them into executable code. Next, the build process usually includes running some preliminary tests, known as unit tests. These ensure the individual components of the application function as expected after the recent changes. Other steps might include packaging the application, where it is put into a format that is suitable for deployment. For a Java application, this might mean creating a JAR or WAR file; for a web app, it might mean bundling JavaScript and CSS files; in Dockerized applications, it might involve building Docker images. Usually, the build is then stored as an 'artifact', a versioned object saved onto an artifact repository for potential deployment later on in the process. Lastly, depending upon the pipeline configuration, linting or static code analysis can also form part of the build process to ensure the code adheres to style and quality standards. It is important to note that the key objective of this build step is to ensure that every change that's integrated continuously into the central codebase is in a releasable state.

181

참고 답변

I would follow these steps: - Assess Impact: Identify affected users and functionalities. - Rollback: If the issue is critical, deploy the last stable version immediately. - Debug & Fix: Analyze logs, run tests, and identify the root cause. - Postmortem: Document the incident, update test cases, and improve monitoring.

182

참고 답변

Blue-Green Deployment is a release management strategy that minimizes downtime and reduces risk by maintaining two separate environments: - Blue Environment (Current Production) – The live environment serving users - Green Environment (New Release) – A copy of the production environment with the updated version of the application How it works: - The new version of the application is deployed to the Green environment while the Blue environment remains active. - Once testing is complete, traffic is switched from Blue to Green, making the new version live. - If any issues arise, traffic can be quickly rolled back to the Blue environment with minimal downtime. Why it matters Interviewers ask this question to test your understanding of deployment strategies that reduce downtime and deployment risk. Blue-Green Deployments allow zero-downtime updates, making them ideal for high-availability applications. For example An e-commerce website implementing a new feature can deploy it in the Green environment while users continue to browse the Blue (live) environment. After verifying the update, traffic is redirected to Green, ensuring a seamless transition without affecting customers.

183

참고 답변

- Declarative Pipelines: Define “what” needs to be done (e.g., Kubernetes YAML files, Terraform). - Imperative Pipelines: Define “how” it should be done step-by-step (e.g., scripting with Bash or Jenkinsfiles). Declarative pipelines are preferred for their readability and maintainability.

184

참고 답변

Ensuring compliance and security in a highly regulated industry involves several steps: - - Use Azure Policy: Enforce organizational standards and assess compliance at-scale. - Implement RBAC: Role-Based Access Control to ensure that only authorized personnel have access to sensitive resources. - Secure pipelines: Use service connections and variable groups with secret management to protect sensitive information. - Monitor and audit: Utilize Azure Monitor and Azure Security Center to track and respond to security incidents. - Compliance certifications: Ensure that the Azure services used are compliant with industry standards such as ISO, SOC, and GDPR.

185

참고 답변

Continuous Integration (CI): Focuses on automating build and test processes for frequent code integration. Continuous Delivery (CD): Extends CI by automating the release process, ensuring code is always deployable but may require manual approval for production. Continuous Deployment (CD): Automatically deploys every change that passes tests to production without manual intervention. Real-World Scenario: An e-commerce platform uses CI to validate code changes, Continuous Delivery to prepare releases for staging, and Continuous Deployment to automatically roll out minor updates to production, ensuring a seamless user experience.

186

참고 답변

Artifact management consists in storing versioned build artifacts (JAR files, docker images) in a repository manager such as Nexus or Artifactory for re-use and traceability.

187

참고 답변

The Dogpile effect is the period after the cache expires and requests have been made on the website from the client. These subsequent requests lead to heavy or slow operations, such as database queries, which can lead to an excessive load on the database or overall service. The Dogpile effect typically happens in high-traffic websites and applications, in which a high increase in workload leads to a decrease in performance or downtime. To prevent the Dogpile effect from happening, you can implement a lock mechanism on the cache so that when the cache expires, and a first request for data comes in, a lock is automatically placed on the cache key. In this case, other requests will have to wait for the lock to be released with the updated cache.

188

참고 답변

By monitoring resource usage, optimizing instance sizes, automating scaling, and exploring reserved and spot instance options.

189

참고 답변

- Chef and Puppet (legacy in some enterprises) - Pulumi (modern IaC with TypeScript/Python support)

190

참고 답변

Monitoring a CI/CD pipeline is crucial to ensuring it works efficiently, reliably, and is always ready for a new deployment. 1. Utilize Integrated Monitoring Tools – Many CI/CD platforms come with built-in monitoring tools that provide real-time insights into pipeline operations. These tools can track the status of builds, deployments, and test executions. 2. Set Up Alerts and Notifications – Configure alerts and notifications for key events, such as build failures, deployment issues, or test result anomalies. For instance, in the Jenkins platform, each job's status can be visually tracked and logs accessed directly. If a job fails, Jenkins can notify users automatically via email or other messaging platforms. 3. Monitor Key Metrics – Track important metrics, including build duration, success/failure rate, deployment frequency, and test result trends. These metrics give insight into the pipeline's health and efficiency. It helps in identifying bottlenecks in the process and guides optimization efforts. 4. Visualize Pipeline Status – Use dashboards to provide a holistic view of the pipeline's status, showing the progress of builds, tests, and deployments. 5. Log Monitoring and Analysis – Implement logging for all stages of the pipeline, capturing detailed information about build processes, errors, and test outputs. Tools like Prometheus, Grafana, or ELK stack can come in handy for this purpose. 6. Continuous Feedback Loops – Establish feedback loops for capturing input from developers and operations teams about ongoing runs. This helps in proactively identifying areas for improvement.

191

참고 답변

DevOps is built on several core principles that drive efficiency, collaboration, and automation in software development and IT operations. These principles ensure that teams can develop, test, deploy, and monitor software quickly and reliably. The key DevOps principles include: - Collaboration & Communication – Breaking down silos between development and operations teams, ensuring shared ownership of software delivery - Automation – Reducing manual tasks in software development, testing, deployment, and monitoring to improve speed and consistency - Continuous Integration & Continuous Deployment (CI/CD) – Frequently integrating and deploying code changes to deliver updates faster with minimal risk - Infrastructure as Code (IaC) – Managing infrastructure using code, enabling consistent, repeatable, and scalable deployments - Monitoring & Feedback – Continuously tracking system performance, identifying issues early, and making iterative improvements Why it matters Interviewers ask this question to test your understanding of the DevOps mindset beyond just tools and technologies. A strong answer should emphasize that DevOps is not just about automation—it's about building a culture of collaboration, feedback, and continuous improvement. For example A company struggling with long deployment cycles might adopt CI/CD to automate testing and releases, reducing deployment time from weeks to hours. Additionally, Infrastructure as Code (IaC) can eliminate inconsistencies in cloud environments, ensuring that staging and production are identical, reducing unexpected failures.

192

참고 답변

Canary deployment is a release strategy where new code is deployed to a small subset of users or systems first. If no issues are reported, the deployment gradually rolls out to the rest. In CI/CD, it can be implemented with orchestration tools like Kubernetes or service meshes like Istio, allowing controlled, low-risk production releases.

193

참고 답변

- Grafana is an open-source analytics and monitoring platform that integrates with various data sources to help users visualize and understand their data. It is widely used for monitoring and observability in IT systems, providing a flexible and customizable interface for creating dashboards, charts, and graphs. - Users can create dashboards that display real-time or historical data through the use of panels and visualizations. - Grafana allows users to set up alert rules based on defined thresholds or conditions. When an alert is triggered, Grafana can send notifications via various channels, such as email, Slack, or other supported notification services. - Grafana supports user authentication and authorization. Users can be organized into teams with specific access permissions, ensuring secure access control to dashboards and data sources.

194

참고 답변

To migrate an existing application into a containerized environment, you'll need to adapt the following steps to your particular context: Figure out what parts of the application need to be containerized together. Create your Dockerfiles and define the entire architecture in that configuration, including the interservice dependencies that there might be. Figure out if you also need to containerize any external dependency, such as a database. If you do, add that to the Dockerfile. Build the actual Docker image. Once you make sure it runs locally, configure the orchestration tool you use to manage the containers. You're now ready to deploy to production, however, make sure you keep monitoring and alerting on any problem shortly after the deployment in case you need to roll back.

195

참고 답변

I ensure compliance and traceability for deployments in regulated environments by implementing mandatory approval gates with digital signatures, logging all pipeline actions with immutable timestamps and user identities, and generating audit trails that link each deployment to specific artifact versions and change requests. I also integrate automated compliance checks for regulatory standards, such as SOC 2 or HIPAA, and use immutable infrastructure to prevent unauthorized changes.

196

참고 답변

I approach artifact versioning by using semantic versioning (e.g., v1.2.3) combined with build metadata (e.g., commit hash) to ensure uniqueness and traceability. Artifacts are stored in a repository with immutable tags, and promotion between environments (e.g., dev, staging, production) is done by copying or linking the same artifact without rebuilding, using pipeline approval gates and automated validation tests at each stage to confirm readiness.

197

참고 답변

CI/CD automates: Container builds Kubernetes deployments Scaling and rollbacks It enables rapid cloud-native innovation.

198

참고 답변

For a successful DevOps implementation, I will follow the following steps: - Define the business objectives - Build cross-functional teams - Adopt agile practices - Automate manual tasks - Implement continuous integration and continuous delivery - Use infrastructure as code - Monitor and measure - Continuously improve - Foster a culture of learning to encourage experimentation and innovation

199

참고 답변

Kubernetes (K8s) is an open source system for orchestrating containers handling deployment, scaling, upgrades, and networking of containerized applications.

200

참고 답변

Container orchestration tools like Kubernetes automate the deployment, scaling, and management of containerized applications in CI/CD pipelines.

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

Cisco, PMP, CISA, CISM, AWS 연습 시험 100% 합격 세일!
지금 받기

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

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

Cisco, PMP, CISA, CISM, AWS 연습 시험 100% 합격 세일! 지금 받기

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

Cisco, PMP, CISA, CISM, AWS 연습 시험 100% 합격 세일!
지금 받기