Network Security Wiki

Google: Difference between revisions

Page Discussion

Google (view source)

Revision as of 06:15, 13 July 2021

18 bytes removed ,  2 years ago
→‎System Design
 
(7 intermediate revisions by the same user not shown)
Line 87:
* Mutex
* Threads
A process is a collection of code, memory, data and other resources.
 
A thread is a sequence of code that is executed within the scope of the process.
You can (usually) have multiple threads executing concurrently within the same process.
 
= Questions =
Line 227 ⟶ 229:
It not, is there any network disconnection/lantency/congestion?
 
SSH Packets are reaching Destination? TCPDump on Destination(look for initial TCP packets with the SYN flags). If not check:
If not check:
- Using IP Correct in client side.
- DNS Correct? try host file entry or direct ip access
Line 239 ⟶ 242:
- Reply packets going or not? if going, check Router reverse routes.
- IPTables Rejecting packets (Flush IPTabeles -F)
- Packets received on correct interface? (SSH might be listening on wrong portinterface/address - ListenAddress )
- SSH fromto Server tofrom localhost
 
Any traffic reaching Server? ifconfig RX, TX count bytes increasing decreasing; If not check:.
If not check:
- Networking Config
- Interface check? correct ip on correct interface?
Line 324 ⟶ 328:
 
*Trade off you made in this?
Used VMs onyonly
Could have used Physical devices - Cisco Call Manager, Physical CBs, Cisco Routers, IPNetSim, IP Phones
Used devices across 2 DCs in India & US.
Line 331 ⟶ 335:
 
*3-tier network design in public cloud. How do you design?
Front End Application
A 3-tier application architecture is a modular client-server architecture that consists of a presentation tier, an application tier and a data tier.
ApplicationBackend tierApplication▼
The data tier stores information, the application tier handles logic and the presentation tier is a graphical user interface (GUI) that communicates with the other two tiers.
Database
The three tiers are logical, not physical, and may or may not run on the same physical server.
 
'''You need LoadBalancer'''
Presentation tier
This tier, which is built with HTML5, cascading style sheets (CSS) and JavaScript, is deployed to a computing device through a web browser or a web-based application.
The presentation tier communicates with the other tiers through application program interface (API) calls.
 
▲ Application tier
The application tier, which may also be referred to as the logic tier, is written in a programming language such as Java and contains the business logic that supports the application’s core functions.
The underlying application tier can either be hosted on distributed servers in the cloud or on a dedicated in-house server, depending on how much processing power the application requires.
 
Data tier
The data tier consists of a database and a program for managing read and write access to a database.
This tier may also be referred to as the storage tier and can be hosted on-premises or in the cloud.
Popular database systems for managing read/write access include MySQL, PostgreSQL, Microsoft SQL Server and MongoDB.
 
*Benefits:
 
Modularity
Teams can focus on different tiers of the application and changes made as quickly as possible.
Helps us recover quickly from an unexpected disaster by focusing solely on the faulty part.
 
Scalability:
Each tier of the architecture can scale horizontally to support the traffic and request demand coming to it.
Can be done by adding more EC2 instances to each tier and load balancing across them.
 
High Availability:
With the traditional data centre, our application is sitting in one geographical location.
With AWS, we can design our application in different locations known as the availability zones.
 
Fault Tolerant:
We want our infrastructure to comfortably adapt to any unexpected change both to traffic and fault.
This is usually done by adding a redundant system that will account for such a hike in traffic when it does occur.
So instead of having two EC2 instances working at 50% each, such that when one instance goes bad, the other instance will be working at 100% capacity until a new instance is brought up by our Auto Scaling Group, we have extra instance making it three instances working at approximately 35% each.
This is usually a tradeoff made against the cost of setting up a redundant system.
 
Security:
Application will communicate within themselves with a private IP.
The presentation (frontend) tier of the infrastructure will be in a private subnet (the subnet with no public IP assigned to its instances) within the VPC.
Users can only reach the frontend through the Application Load Balancer.
Backend and Database tier will also be in the private subnet because we do not want to expose them over the internet.
We will set up the Bastion host for remote SSH and a NAT gateway for our private subnets to access the internet.
 
*Will you need LB? Why?
Line 445 ⟶ 411:
== Re-Evaluate the design ==
Room for improvement?
 
= Dublin =
 
 
== Interview 1 (45 mins) ==
 
;Technical RRK - Foundational technical knowledge where the interviewer will ask you at least one question from 2-3 areas based on your expertise. This would include areas like (but not all)
* Connectivity (Layer-2 switching)
* Connectivity (Layer-3 IP routing)
* Network hardware devices
* Network hardware performance
* Webtech/troubleshooting/SQL
 
;Troubleshooting - Focus on process of troubleshooting rather than technical details
* Networking troubleshooting questions to demonstrate you can apply knowledge of Networking specific technologies to troubleshoot specific problems
;System Design -
 
* Designing technical solutions
 
== Interview 2 (45 mins) ==
;HrM Interview - This interview is based around the below criteria. This is some but not all they will cover.
* Handling customer issues
* Long term customer success
* Escalating handling
 
 
;A few additional tips which may help in your preparations:
 
* Talk through your thought process about the questions you are asked. In all of Google's interviews, our engineers are evaluating not only your technical abilities but also how you approach problems and how you try to solve them.
 
* Ask clarifying questions if you do not understand the problem or need more information. Many of the questions asked in Google interviews are deliberately underspecified because our engineers are looking to see how you engage the problem. In particular, they are looking to see which areas leap to your mind as the most important piece of the technological puzzle you've been presented.
 
* Think about ways to improve the solution you'll present. In many cases, the first answer that springs to mind isn't the most elegant solution and may need some refining. It's definitely worthwhile to talk about your initial thoughts to a question, but jumping immediately into presenting a brute force solution will be received less well than taking time to compose a more efficient solution.
 
* When asked a question by the interviewer '''your answer should''' be:
 
SPECIFIC: inline with the question, no digressions.
SYNTHETIC: be factual, simple, short sentences, no long explanations. Inform the interviewer that you have additional info if he would like to know more.
TECHNICAL: your interviewer is an expert and they love to hear deep technical details in your answers (relevant to the question of course)... They are eager to learn something new.
OPEN: if you don't know the answer to the question it is not a problem but please please please tell the interviewer, don't pretend that you know by just guessing the answer. Tell them that you will attempt a solution by using the following X Y Z elements. ALWAYS explain the reasoning that you are following.
FLUID: keep the conversation going, no long blank moments, if you need additional information about the problem you are asked to solve, ask the interviewer. The interview is a conversation not a monologue, not an exam.
Retrieved from "https://aman.awiki.org/wiki/Special:MobileDiff/4034...4542"