Github actions Questions

 Question 1: What is GitHub Actions?

Answer 1: GitHub Actions is a CI/CD tool to automate workflows directly within GitHub repositories.

Question 2: What are GitHub workflows?
Answer 2: Workflows are automated processes defined in .github/workflows/*.yml files.

Question 3: What is a job in GitHub Actions?
Answer 3: A job is a set of steps executed in a runner.

Question 4: What is a runner in GitHub Actions?
Answer 4: A runner is a machine that executes workflow jobs.

Question 5: What are GitHub-hosted runners?
Answer 5: GitHub-hosted runners are managed by GitHub and run workflows in virtual machines.

Question 6: What are self-hosted runners?
Answer 6: Self-hosted runners are user-managed machines for executing workflows.

Question 7: What is a step in GitHub Actions?
Answer 7: A step is an individual task within a job.

Question 8: What is an event in GitHub Actions?
Answer 8: An event is a trigger that starts a workflow.

Question 9: What are some common GitHub Actions events?
Answer 9: push, pull_request, schedule, workflow_dispatch.

Question 10: What is the syntax of a GitHub Actions workflow?
Answer 10: YAML (.yml) syntax.

Question 11: Where are GitHub Actions workflows stored?
Answer 11: In .github/workflows/ directory.

Question 12: How do you trigger a workflow manually?
Answer 12: Using workflow_dispatch.

Question 13: What is on: push in a workflow?
Answer 13: It triggers a workflow when code is pushed.

Question 14: How do you specify a specific branch in a workflow trigger?
Answer 14: Use on: push: branches: [branch-name].

Question 15: What is on: pull_request?
Answer 15: It triggers a workflow on pull request events.

Question 16: What is a matrix in GitHub Actions?
Answer 16: It allows running jobs with multiple configurations.

Question 17: How do you define environment variables?
Answer 17: Using env: in the workflow.

Question 18: How do you access environment variables?
Answer 18: Using ${{ env.VARIABLE_NAME }}.

Question 19: How do you store secrets in GitHub Actions?
Answer 19: Using GitHub repository secrets.

Question 20: How do you use secrets in workflows?
Answer 20: ${{ secrets.SECRET_NAME }}.

Question 21: What is jobs.<job-id>.strategy.matrix used for?
Answer 21: It enables parallel execution with different parameters.

Question 22: How do you define a job dependency?
Answer 22: Using needs:.

Question 23: Can jobs run in parallel?
Answer 23: Yes, unless dependencies are defined.

Question 24: What is an artifact in GitHub Actions?
Answer 24: A file or data stored between jobs.

Question 25: How do you upload artifacts?
Answer 25: Using actions/upload-artifact.

Question 26: How do you download artifacts?
Answer 26: Using actions/download-artifact.

Question 27: What is the default shell in GitHub Actions?
Answer 27: Bash.

Question 28: Can you use PowerShell in GitHub Actions?
Answer 28: Yes, by specifying shell: pwsh.

Question 29: How do you run a specific script in a step?
Answer 29: Using run: ./script.sh.

Question 30: How do you define an action?
Answer 30: Using uses: owner/repo@version.

Question 31: What is a reusable workflow?
Answer 31: A workflow that can be called from another workflow.

Question 32: How do you call a reusable workflow?
Answer 32: Using uses: with a path to the workflow.

Question 33: What is an if condition in GitHub Actions?
Answer 33: A way to conditionally run a step or job.

Question 34: How do you check the status of a previous step?
Answer 34: Using if: success(), if: failure().

Question 35: How do you trigger a workflow at a specific time?
Answer 35: Using on: schedule: with cron syntax.

Question 36: What is a composite action?
Answer 36: A custom action combining multiple steps.

Question 37: What is the default timeout for a job?
Answer 37: 360 minutes.

Question 38: How do you set a custom timeout?
Answer 38: Using timeout-minutes:.

Question 39: What is continue-on-error?
Answer 39: Allows a step to fail without failing the job.

Question 40: How do you cancel a running workflow?
Answer 40: Via the GitHub Actions UI or API.

Question 41: How do you debug a failing GitHub Action?
Answer 41: Enable ACTIONS_STEP_DEBUG secret.

Question 42: What is GITHUB_TOKEN?
Answer 42: An auto-generated token for authentication.

Question 43: How do you pass data between jobs?
Answer 43: Using artifacts or outputs.

Question 44: What is a GitHub Actions environment?
Answer 44: A deployment environment with specific secrets.

Question 45: How do you rollback a failed deployment?
Answer 45: Use a previous release or redeploy a stable version.

Question 46: Can GitHub Actions deploy to AWS?
Answer 46: Yes, using AWS CLI or GitHub Actions for AWS.

Question 47: How do you deploy to Kubernetes?
Answer 47: Use kubectl in GitHub Actions.

Question 48: How do you cache dependencies?
Answer 48: Using actions/cache.

Question 49: How do you test a GitHub Actions workflow locally?
Answer 49: Using act CLI.

Question 50: How do you restrict a workflow to specific branches?
Answer 50: Using on: push: branches: [main].

How Does Kubernetes Handle CPU and Memory Limits?

 Kubernetes manages CPU and memory resources for containers using two primary configurations: requests and limits, which influence both scheduling and runtime enforcement.

1. CPU Management

CPU Requests

• Represent the minimum guaranteed CPU a container can access.
• The kube-scheduler uses requests to place Pods on nodes with sufficient available CPU.
• CPU is compressible, meaning a container can temporarily exceed its request if spare cycles exist.

CPU Limits

• Define the maximum CPU a container may consume.
• Enforced via Linux cgroups using the Completely Fair Scheduler (CFS):
  • cpu.cfs_quota_us specifies microseconds per scheduling period (cpu.cfs_period_us) a container may consume.
  • Exceeding the limit triggers CPU throttling, slowing the container without killing it.
• Behavioral nuances:
  • Throttling occurs only when multiple containers compete for limited CPU.
  • Unused CPU is reallocated proportionally to containers based on their requests and priority (QoS class).

2. Memory Management

Memory Requests

• Indicate the minimum memory guaranteed to a container.
• Scheduler ensures the host node has enough free memory for requested allocations.

Memory Limits

• Specify the maximum memory a container can use.
• Memory is incompressible: exceeding the limit may trigger:
  • OOM (Out-of-Memory) kills by the Linux kernel.
  • If container is terminated and restartPolicy allows, Kubernetes restarts it.
• Unlike CPU, exceeding memory limits usually results in immediate termination under memory pressure.

Notes on Enforcement

• Memory enforcement is reactive, occurring only if the kernel detects memory pressure.
• Kubernetes tracks Pod QoS class (Guaranteed, Burstable, BestEffort) to prioritize OOM eviction:
  • Guaranteed: request = limit; least likely to be killed.
  • Burstable: request < limit; may be killed under pressure.
  • BestEffort: no requests/limits; first to be evicted when memory is scarce.

3. Pod-Level Resource Aggregation

• A Pod’s total CPU or memory requests/limits are the sum of its containers’ configurations.
• Kubernetes now supports Pod-level resource requests/limits, allowing containers within a Pod to share idle resources dynamically.

4. Best Practices

• Always set requests and limits to ensure scheduling stability and prevent runaway consumption.
• For CPU, prioritize requests over hard limits to avoid performance throttling in bursty workloads.
• For memory, set realistic limits above expected peak usage to reduce OOM kills.
• Use QoS classes, HPA (Horizontal Pod Autoscaler), and VPA (Vertical Pod Autoscaler) to dynamically adjust resources.
• Monitor CPU and memory with tools like kubectl top pod, Prometheus metrics (container_cpu_cfs_throttled_seconds_total, container_memory_usage_bytes), and Node PSI (Pressure Stall Information).
• CPU is compressible, meaning a container can temporarily exceed its request if spare cycles exist.

CPU Limits

• Define the maximum CPU a container may consume.
• Enforced via Linux cgroups using the Completely Fair Scheduler (CFS):
  • cpu.cfs_quota_us specifies microseconds per scheduling period (cpu.cfs_period_us) a container may consume.
  • Exceeding the limit triggers CPU throttling, slowing the container without killing it.
• Behavioral nuances:
  • Throttling occurs only when multiple containers compete for limited CPU.
  • Unused CPU is reallocated proportionally to containers based on their requests and priority (QoS class).

2. Memory Management

Memory Requests

• Indicate the minimum memory guaranteed to a container.
• Scheduler ensures the host node has enough free memory for requested allocations.

Memory Limits

• Specify the maximum memory a container can use.
• Memory is incompressible: exceeding the limit may trigger:
  • OOM (Out-of-Memory) kills by the Linux kernel.
  • If container is terminated and restartPolicy allows, Kubernetes restarts it.
• Unlike CPU, exceeding memory limits usually results in immediate termination under memory pressure.

Notes on Enforcement

• Memory enforcement is reactive, occurring only if the kernel detects memory pressure.
• Kubernetes tracks Pod QoS class (Guaranteed, Burstable, BestEffort) to prioritize OOM eviction:
  • Guaranteed: request = limit; least likely to be killed.
  • Burstable: request < limit; may be killed under pressure.
  • BestEffort: no requests/limits; first to be evicted when memory is scarce.

3. Pod-Level Resource Aggregation

• A Pod’s total CPU or memory requests/limits are the sum of its containers’ configurations.
• Kubernetes now supports Pod-level resource requests/limits, allowing containers within a Pod to share idle resources dynamically.

4. Best Practices

• Always set requests and limits to ensure scheduling stability and prevent runaway consumption.
• For CPU, prioritize requests over hard limits to avoid performance throttling in bursty workloads.
• For memory, set realistic limits above expected peak usage to reduce OOM kills.
• Use QoS classes, HPA (Horizontal Pod Autoscaler), and VPA (Vertical Pod Autoscaler) to dynamically adjust resources.
• Monitor CPU and memory with tools like kubectl top pod, Prometheus metrics (container_cpu_cfs_throttled_seconds_total, container_memory_usage_bytes), and Node PSI (Pressure Stall Information).
• 
  

Key Takeaways:

• CPU limits are throttled; memory limits are terminated.
• Requests ensure Pod placement; limits enforce runtime constraints.
• Pods’ performance and cluster stability depend on setting proper requests and limits, aligned with workload characteristics.

IAC and DevOps asks

 Terraform Questions: Core Concepts

1. Explain the differences between Terraform Open Source, Terraform Cloud, and Terraform Enterprise.

 Open Source: Local execution, manual state management (e.g., S3, Consul), basic CLI workflows, no governance features.

 Terraform Cloud: SaaS offering by HashiCorp, includes remote state storage, remote execution, VCS integration, workspace management, basic RBAC, and Sentinel policy enforcement.

 Terraform Enterprise: Self-hosted/private instance version of Terraform Cloud with advanced governance features, enterprise-grade integrations, full RBAC, policy enforcement, private networking, and auditing suited for regulated environments.

2. What is a “Workspace” in Terraform Cloud/TFE and how does it differ from a local Terraform workspace?

 Local Workspace: Isolated directory with separate state files on your machine.

 Terraform Cloud/TFE Workspace: Logical construct in the platform that stores state remotely, links to VCS, has its own variables, runs, permissions, and policies. Essentially, a workspace = environment-specific pipeline for infra deployments.

3. Purpose of the “Sentinel” policy framework.

 Sentinel allows you to define fine-grained, logic-based governance policies (written in Sentinel’s language) that run on every Terraform plan before apply.

 Examples: Enforce tagging, restrict instance sizes, prevent certain regions.

4. Remote Execution benefits.

 Terraform runs happen in HashiCorp-managed (Cloud) or self-hosted (Enterprise) infrastructure. Benefits:

o No local dependency on Terraform version.

o Secure state storage & lock management.

o Isolated execution environment for consistency across teams.

5. State management in TFE vs Terraform OSS.

 OSS requires you to configure a remote backend like S3 + DynamoDB or Consul for locking.

 Cloud/Enterprise automatically manages state in a secure, encrypted backend with UI access, version history, and locking built-in.

6. VCS-driven vs API-driven workflows.

 VCS-driven: Changes are pushed to a Git repository, Terraform Cloud detects commits and triggers runs.

CONFIDENTIAL AND PROPRIETARY

 API-driven: Runs initiated via Terraform Cloud/TFE API, useful for pipeline integrations (Jenkins, Azure DevOps, etc.).

23. Debug failed run.

 View run logs in TFE/Cloud UI.

 Check Sentinel policy violations, backend errors, credentials.

24. Logs in TFE.

 Docker container logs, Replicated admin dashboard, application logs for API/UI.

25. State lock timeout.

 Cloud/TFE automatically releases lock after timeout or manual intervention in UI.

26. Drift detection.

 Compare real infrastructure state vs Terraform state (via plan).

 Terraform Cloud can auto-detect drift via scheduled runs.

27. State migration to TFE.

 Use terraform state pull locally → configure remote backend → terraform state push to TFE.

28. Multiple vs single workspace.

 Multiple workspaces per environment = clean separation of variables, state, history.

 Single workspace with variables → risk of accidental overlap.

29. Remote backend advantages.

 Consistent team collaboration, secure state management, history tracking, built-in locking.

30. Tagging enforcement using Sentinel.

 Example policy: Require Environment and Owner tags for all AWS resources.

 Runs automatically on every plan to enforce compliance.

CONFIDENTIAL AND PROPRIETARY

Azure Devops Questions:

1. How do you implement multi-stage pipelines in Azure DevOps?

Answer:

 Multi-stage pipelines in Azure DevOps are defined in YAML and allow you to have different stages like Build, Test, and Deploy within one pipeline.

 Each stage can have multiple jobs, and jobs can have multiple steps.

 Example process:

1. Build Stage → Compile code, run unit tests.

2. Test Stage → Run integration tests.

3. Deploy Stage → Deploy to specific environments.

 You can define these in YAML using stages: keyword.

 Benefits:

 Single pipeline for all phases.

 Easier approval and environment tracking.

 Reusability and clarity in the deployment process.

 Example YAML snippet:

yaml

Copy code

stages: - stage: Build jobs: - job: build steps: - script: dotnet build - stage: DeployDev jobs: - job: deploy steps: - script: echo "Deploying to Dev" - stage: DeployProd dependsOn: DeployDev jobs: - job: deploy steps: - script: echo "Deploying to Prod"

2. Deploy to Multiple Environments (Dev, QA, Prod) Using One Pipeline

Answer:

 Use multi-stage pipelines with environment-specific variables.

 Create separate deployment stages for each environment.

 Configure:

 Environment names in Azure DevOps (visible in Releases → Environments section).

 Approvals & checks per environment.

 Variable groups to store environment-specific configs (e.g., connection strings, API keys).

CONFIDENTIAL AND PROPRIETARY

 Optionally, integrate deployment conditions so that QA deploy runs only after Dev is successful, and Prod only after QA.

 YAML example:

yaml

Copy code

stages: - stage: DeployDev variables: envName: 'Dev' jobs: - deployment: DeployDev environment: Dev strategy: runOnce: deploy: steps: - script: echo Deploying to Dev - stage: DeployQA dependsOn: DeployDev variables: envName: 'QA' jobs: - deployment: DeployQA environment: QA strategy: runOnce: deploy: steps: - script: echo Deploying to QA - stage: DeployProd dependsOn: DeployQA variables: envName: 'Prod' jobs: - deployment: DeployProd environment: Prod strategy: runOnce: deploy: steps: - script: echo Deploying to Prod

3. Setting Up Approvals and Gates in a Pipeline

Answer:

 Approvals: Require manual confirmation before moving to the next stage/environment.

 Navigate to Project Settings → Pipelines → Environments, select environment, then add Approvals.

 Assign one or more users/groups who must approve before deployment continues.

 Gates: Automatically check external conditions before deployment.

 Example gates:

 Query work items.

 Invoke REST API.

 Check Azure Monitor metrics.

 Configure gates under environment's “Checks” settings.

 Benefits:

 Control production deployments.

 Integrate automated quality or compliance checks.

4. Integrating Azure DevOps with External Tools (Jira, SonarQube, Kubernetes)

Answer:

 Jira:

 Use Service Hooks or Azure DevOps Marketplace extensions.

 Map Azure Boards work items ↔ Jira issues.

 Can automate status updates when commits/pipeline runs occur.

CONFIDENTIAL AND PROPRIETARY

 SonarQube:

 Install the SonarQube extension.

 Add SonarQubePrepare, SonarQubeAnalyze, and SonarQubePublish tasks in your pipeline.

 Requires setting up a Service Connection with SonarQube server.

 Kubernetes:

 Create a Service Connection for the Kubernetes cluster.

 Use kubectl commands or Helm tasks inside the pipeline.

 Deploy manifests or charts via YAML job targeting the K8s environment.

 Key steps for integration:

1. Install necessary extension from Marketplace.

2. Set up Service Connection (to authenticate).

3. Configure required tasks in the pipeline with correct credentials.

5. Implementing Blue-Green or Canary Deployment in Azure DevOps

Answer:

 Blue-Green Deployment:

 Maintain two identical production environments: Blue and Green.

 Route traffic to one environment while updating the other.

 Use Azure DevOps pipeline + deployment stage to update idle environment.

 After testing, switch traffic using Azure Traffic Manager or Application Gateway.

 Canary Deployment:

 Gradually roll out changes to a small percentage of users before full rollout.

 Configure deployment pipeline to push updates to a subset of servers/pods first.

 Once validated, continue rollout to all users.

 Implementation:

 Use multi-stage YAML pipeline with strategies (rolling, canary) in deployment jobs.

 Integrate with Kubernetes or App Service slots.

 Example (App Service Slot swap for Blue-Green):

yaml

Copy code

CONFIDENTIAL AND PROPRIETARY

- task: AzureWebApp@1 inputs: azureSubscription: 'MyServiceConnection' appName: 'my-app' slotName: 'staging' - task: AzureAppServiceManage@0 inputs: azureSubscription: 'MyServiceConnection' WebAppName: 'my-app' Action: 'Swap Slots' SourceSlot: 'staging' TargetSlot: 'production'

6. Troubleshooting a Failed Azure Pipeline Run

Answer:

1. Check Logs:

 View logs in the pipeline run details page.

 Check the specific failing step — Azure DevOps shows detailed job/task logs.

2. Reproduce Locally:

 Try running the same commands/build locally to isolate CI/CD-specific issues.

3. Validate Configs:

 Check YAML syntax errors using pipeline linting.

 Ensure variable names/values are correct.

 Verify Service Connections and credentials.

4. Dependency & Environment Checks:

 Validate agent capabilities (e.g., correct .NET SDK version, Node, Docker).

 Check external dependencies (database, APIs).

5. Retry & Debug Mode:

 Enable system diagnostics (system.debug: true in variables) for extra logs.

6. Common causes:

 Misconfigured paths.

 Missing environment variables.

 Expired credentials or secrets.

 Incorrect artifact paths between stages.

What is the purpose of service connections in Azure DevOps?

The purpose of Service Connections in Azure DevOps is to securely store and manage authentication details needed for pipelines to connect to external or remote resources.

Key points:

 They allow your build and release pipelines to access external services such as Azure, AWS, Docker Hub, GitHub, Kubernetes clusters, SonarQube, etc.