GitHub is a web-based platform that uses Git for version control and allows developers to collaborate on projects. The main difference is that Git is a version control system used to manage code changes locally, while GitHub provides a cloud-based interface for hosting Git repositories, facilitating collaboration, and offering additional features like issue tracking and project management.

To create an issue on GitHub, go to the "Issues" tab of your repository, click on "New issue," fill in the title and description, and then click "Submit new issue." Issues are useful for tracking tasks, bugs, feature requests, and discussions, helping teams organize and prioritize their work.
A fork in GitHub is a copy of a repository that allows you to make changes without affecting the original project. It is used to propose changes, experiment with new ideas, or contribute to the original repository by submitting pull requests.
A pull request (PR) is a request to merge code changes from one branch into another in a repository. The workflow typically involves the following steps:
1. A developer creates a new branch and makes changes to the code.
2. The developer pushes the branch to the remote repository.
3. The developer opens a pull request, specifying the branch to merge into and providing a description of the changes.
4. Team members review the pull request, provide feedback, and may request changes.
5. Once approved, the pull request is merged into the target branch.
6. The branch can then be deleted if no longer needed.
To review and approve a pull request on GitHub, follow these steps:
1. Navigate to the repository and click on the "Pull requests" tab.
2. Select the pull request you want to review.
3. Review the changes by clicking on the "Files changed" tab.
4. Add comments or suggestions if needed using the comment feature.
5. If you approve the changes, click on the "Review changes" button.
6. Select "Approve" and add any comments if desired.
7. Click "Submit review" to finalize your approval.
In GitLab CI/CD, you use artifacts and caches to manage files between pipeline jobs:
🔹 Artifacts:
-
Used to pass files from one job to another.
-
Saved files after a job finishes (e.g., compiled binaries, test reports).
-
Defined using:
🔹 Cache:
-
Used to speed up jobs by reusing dependencies (like npm packages, pip installs).
-
Not passed between jobs but stored for reuse.
-
Defined using:
✅ Use artifacts to share outputs.
✅ Use cache to reduce build time.
In GitLab, access control is managed using:
1. Project & Group Memberships:
-
Users are assigned roles at the project or group level.
2. Role-Based Permissions:
Common roles include:
-
Guest – limited access (issues, comments)
-
Reporter – can view and download code
-
Developer – can push code, create branches
-
Maintainer – full access, including CI/CD and settings
-
Owner (group level only) – manage everything, including members
3. Private, Internal, and Public Visibility:
-
Controls who can access the project/repo.
4. Protected Branches and Tags:
-
Limit who can push, merge, or delete branches/tags.
5. Access Tokens:
-
Personal, project, or group access tokens for CI/CD or API use.
These tools together help enforce secure and flexible access policies in GitLab.
Jira Integration with GitLab
-
Go to GitLab:
→Settings
→Integrations
→ Select Jira -
Enter:
-
Jira URL
-
Project Key
-
Username + API token
-
-
Enables:
-
Linking GitLab commits/MRs to Jira issues using
JIRA-123
in commit messages -
Jira issue status updates
-
✅ Slack Integration with GitLab
-
Go to GitLab:
→Settings
→Integrations
→ Select Slack notifications -
Enter:
-
Webhook URL (from your Slack app or channel)
-
Channel name
-
Choose events (push, merge request, pipeline, etc.)
-
-
Enables:
-
GitLab events trigger messages in Slack channels
-
✅ Other Tools (e.g., Trello, Microsoft Teams, Jenkins)
-
GitLab supports integrations via:
-
Webhooks
-
API tokens
-
Custom scripts in
.gitlab-ci.yml
-
GitLab Apps/Marketplace
-
Example webhook:
→ Settings
→ Webhooks
→ Add URL of external service and select trigger events
The difference between Shared and Specific Runners in GitLab:
🔹 Shared Runners
-
Available to all projects in a GitLab instance.
-
Useful for CI/CD across multiple projects.
-
Maintained by GitLab or an admin.
-
Suitable for general-purpose jobs.
🔹 Specific Runners
-
Assigned to a specific project or group.
-
Provide more control over the runner environment.
-
Ideal for jobs that need special dependencies or isolation.
✅ Use Shared Runners for simplicity.
✅ Use Specific Runners for customization or security.
In GitOps:
-
Used GitLab as the single source of truth for infrastructure as code.
-
Implemented CI/CD pipelines to auto-deploy to Kubernetes clusters using tools like ArgoCD or Flux.
-
Managed environment states entirely through version-controlled Git repositories.
In DevSecOps:
-
Integrated GitLab’s built-in security features (SAST, DAST, dependency scanning, secret detection) into pipelines.
-
Enforced security checks before merge approvals.
-
Used GitLab CI/CD to automate compliance and vulnerability checks throughout the development lifecycle.
Overall, GitLab streamlined the deployment and security process through automation and transparency.
Amazon S3 (Simple Storage Service) is an object storage service designed for storing and retrieving any amount of data from anywhere on the web, while Amazon EBS (Elastic Block Store) is a block storage service used with Amazon EC2 instances for storing data that requires low-latency access, such as file systems and databases.
Amazon Route 53 is a scalable and highly available Domain Name System (DNS) web service that translates domain names into IP addresses, helping to route end users to Internet applications.
An Elastic Load Balancer (ELB) is a service that automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, and IP addresses, to ensure high availability and reliability of applications.
AWS CLI (Amazon Web Services Command Line Interface) is a tool that allows users to interact with AWS services using command-line commands instead of the web-based console.
Elastic Beanstalk is a platform-as-a-service (PaaS) that simplifies application deployment and management, automatically handling infrastructure provisioning, load balancing, and scaling. CloudFormation, on the other hand, is an infrastructure-as-code (IaC) service that allows you to define and provision AWS resources using templates, giving you more control over the infrastructure setup but requiring more manual configuration.
Azure Active Directory (Azure AD) is a cloud-based identity and access management service from Microsoft. It helps organizations manage user identities and access to resources securely. Azure AD is used for single sign-on (SSO), multi-factor authentication (MFA), and managing user permissions for applications and services in the cloud and on-premises.
Azure Load Balancer operates at the transport layer (Layer 4) and distributes incoming traffic based on IP address and port, while Azure Application Gateway operates at the application layer (Layer 7) and provides features like URL-based routing, SSL termination, and Web Application Firewall (WAF) capabilities.
Azure Resource Manager (ARM) is a management framework in Microsoft Azure that allows users to create, update, and delete resources in their Azure account. It manages resources through a consistent management layer, enabling users to deploy resources in a declarative manner using templates, organize resources into resource groups, and apply role-based access control (RBAC) for security and management.
The different types of cloud deployment models in Azure are:
1. Public Cloud
2. Private Cloud
3. Hybrid Cloud
4. Multi-Cloud
Azure Monitor is a comprehensive service that provides performance and diagnostic data for applications and infrastructure in Azure. It helps by collecting, analyzing, and acting on telemetry data from various resources, enabling users to monitor application performance, identify issues, and gain insights for optimization and troubleshooting.