Google Professional Cloud Architect Exam Actual Questions#3

21. Your company's user-feedback portal comprises a standard LAMP stack replicated across two zones. It is deployed in the us-central1 region and uses autoscaled managed instance groups on all layers, except the database. Currently, only a small group of select customers have access to the portal. The portal meets a 99,99% availability SLA under these conditions. However next quarter, your company will be making the portal available to all users, including unauthenticated users. You need to develop a resiliency testing strategy to ensure the system maintains the SLA once they introduce additional user load.
What should you do?

• A. Capture existing users input, and replay captured user load until autoscale is triggered on all layers. At the same time, terminate all resources in one of the zones
• B. Create synthetic random user input, replay synthetic load until autoscale logic is triggered on at least one layer, and introduce ג€chaosג€ to the system by terminating random resources on both zones
• C. Expose the new system to a larger group of users, and increase group size each day until autoscale logic is triggered on all layers. At the same time, terminate random resources on both zones
• D. Capture existing users input, and replay captured user load until resource utilization crosses 80%. Also, derive estimated number of users based on existing user's usage of the app, and deploy enough resources to handle 200% of expected load

사용자 피드백 포탈은 2개의 구역에 걸쳐서 복제된 표준 LAMP 스택으로 구성돼 있다. s-central1 리전에 배포되며, 데이터베이스를 제외한 모든 계층에서 자동 확장 관리 인스턴스 그룹을 사용한다. 현재는 소수의 선택된 고객 그룹만이 포탈에 액세스할 수 있다. 포탈은 99.99%의 가용성 SLA를 제공한다. 하지만 다음 분기에 인증되지 않은 사용자를 포함한 모든 사용자가 포탈을 사용할 수 있도록 할 것이다. 시스템이 사용자 부하를 추가로 도입한 후에도 SLA를 유지할 수 있도록 복원력 테스트 전략을 수립해야 한다. 이때의 행동으로 옳은 것은.

 

여기서 핵심은 부하 테스트와 신뢰성 테스트를 통과해야 한다는 점이다. A는 하나의 구역만 테스트하고, B는 둘다 하며, C는 실제 사용자 환경에 영향을 미칠 뿐이다. D는 정말 전혀 연관이 없다. https://cloud.google.com/solutions/scalable-and-resilient-apps#test_your_resilience에서 복원력 테스트 내용을 통해 B의 내용에 대해 확신을 얻을 수 있다. 합성 무작위 사용자 입력을 생성하고 로드를 재생함으로써 예상되는 사용자 트래픽 증가를 시뮬레이션하고, 애플리케이션의 여러 계층에서 자동 스케일 로직을 트리거할 수 있다. 두 구역 모두에서 무작위 리소스를 종료하여 시스템에 혼돈을 도입하면 스트레스를 받는 시스템의 복원력과 이중화를 테스트하는 데 도움이 된다. 이 전략은 시스템이 추가 사용자 부하를 받을 때 99.99% 가용성 SLA를 유지할 수 있도록 보장하는 데 도움이 된다.

 

22. One of the developers on your team deployed their application in Google Container Engine with the Dockerfile below. They report that their application deployments are taking too long.

You want to optimize this Dockerfile for faster deployment times without adversely affecting the app's functionality.
Which two actions should you take? (Choose two.)

• A. Remove Python after running pip
• B. Remove dependencies from requirements.txt
• C. Use a slimmed-down base image like Alpine Linux
• D. Use larger machine types for your Google Container Engine node pools
• E. Copy the source after he package dependencies (Python and pip) are installed

위의 도커 파일과 함께 구글 컨테이너 엔진에 컨테이너를 배포했다. 그런데 애플리케이션 배포에 너무 많은 시간이 걸리는 상황이다. 앱의 기능에 악영향을 주지 않으면서, 더 빠른 배포 시간을 위해 이 도커 파일을 최적화하는 2가지 방법은.

 

C에서 의존성을 최소화한 기본 이미지가 작으면, 컨테이너가 더 빨리 시작된다. E에서 도커 이미지 빌드는 캐싱을 사용한다. 도커 명령 시퀀스는 애플리케이션의 종속성이 파이썬 코드보다 덜 변경되기 때문에 캐시된 종속성 계층을 재사용하고 파이썬 소스 코드의 변경을 위해 새 계층만 추가하는 데 도움이 된다. https://www.docker.com/blog/intro-guide-to-dockerfile-best-practices/과 https://docs.docker.com/build/cache/에서 이것에 대한 확신을 얻을 수 있다.

 

23. Your solution is producing performance bugs in production that you did not see in staging and test environments. You want to adjust your test and deployment procedures to avoid this problem in the future.
What should you do?

• A. Deploy fewer changes to production
• B. Deploy smaller changes to production
• C. Increase the load on your test and staging environments
• D. Deploy changes to a small subset of users before rolling out to production

스테이징 및 테스트 환경에서 볼 수 없었던 성능 버그를 프로덕션에서 생성하는 솔루션이 있다. 향후 이 문제를 방지하고자 테스트 및 배포 절차를 조정하려 한다. 

 

부하 증가인지 변경사항 배포인지 다소 헷갈린다. 그런데 여기서는 C를 고르겠다. 변경 사항을 사용자의 작은 서브셋에 배포하는 것만으로는 성능 버그를 강조하기에 '충분한' 부하가 걸리는지 불확실하다. 또한, 운영 중에 버그가 한 번 발생하더라도, '향후 이 문제를 방지하기 위해'라는 문제의 요구사항을 충족하지 못한다. 그렇기에 롤백으로 수정하는 것이 더 빠를 것이다. 결국 핵심은 '성능 버그' 탐지인 것이고, 여기에 있어서는 C가 가장 적합한 것으로 보인다.

 

24. A small number of API requests to your microservices-based application take a very long time. You know that each request to the API can traverse many services.
You want to know which service takes the longest in those cases.
What should you do?

• A. Set timeouts on your application so that you can fail requests faster
• B. Send custom metrics for each of your requests to Stackdriver Monitoring
• C. Use Stackdriver Monitoring to look for insights that show when your API latencies are high
• D. Instrument your application with Stackdriver Trace in order to break down the request latencies at each microservice

마이크로서비스 기반 애플리케이션에 대한 적은 수의 API 요청은 매우 오랜 시간이 걸린다. API에 대한 각 요청은 많은 서비스를 통과할 수 있다는 것을 이미 알고 있다. 그렇다면 어떤 서비스가 오래 걸리는지 알기 위해서는 어떻게 해야 하는가.

스택드라이버 트레이스는 분산 추적 시스템으로, 각 요청과 요청이 애플리케이션을 통과할 때 터치하는 다양한 마이크로 서비스 간의 관계를 이해할 수 있다. 스택드라이버 트레이스로 애플리케이션을 계측하면 각 마이크로서비스의 지연 시간을 자세히 분석할 수 있어 적은 수의 API 요청이 매우 오래 걸리는 경우 어떤 서비스가 가장 오래 걸리는지 확인하는 데 도움이 될 것이다. A의 애플리케이션에 시간 제한을 설정하거나 B의 스택 드라이버 모니터링에 사용자 지정 메트릭을 보내는 것은 지연 시간 문제를 일으키는 특정 서비스를 식별하는 데 필요한 세부 정보 수준을 제공하지 않을 수 있다. C의 스택 드라이버 모니터링에서 통찰력을 찾는 것도 각 마이크로 서비스의 개별 지연 시간을 보여주지 못하기 때문에 필요한 세부 정보 수준을 제공하지 않을 것으로 보인다.

 

25. During a high traffic portion of the day, one of your relational databases crashes, but the replica is never promoted to a master. You want to avoid this in the future.
What should you do?

• A. Use a different database
• B. Choose larger instances for your database
• C. Create snapshots of your database more regularly
• D. Implement routinely scheduled failovers of your databases

하루 중 트래픽이 많은 시간 동안 관계형 데이터베이스 중 하나가 충돌한다. 그러나 레플리케이션이 마스터로 승격하질 못하는 실정. 이 문제를 방지하기 위한 해결책은.

 

여기서 충돌은 하는데, 충돌의 원인이 있지 않아서 다소 애매하긴 하다. 이것이 하중 때문인지 무엇인지 명확하지 않으므로 D가 여기서는 합당한 선택으로 보인다. 일상적인 페일오버는 시스템이 충돌에 대해 탄력적으로 작동하는지 확인하는 데 도움이 된다.

 

26. Your organization requires that metrics from all applications be retained for 5 years for future analysis in possible legal proceedings.
Which approach should you use?

• A. Grant the security team access to the logs in each Project
• B. Configure Stackdriver Monitoring for all Projects, and export to BigQuery
• C. Configure Stackdriver Monitoring for all Projects with the default retention policies
• D. Configure Stackdriver Monitoring for all Projects, and export to Google Cloud Storage

향후 법적 절차에 있어 분석을 위해 모든 애플리케이션에서 메트릭을 5년 동안 유지해야 한다. 어떤 접근법을 사용해야 하는가.

 

우선 A와 C는 빠르게 배제된다. 요구사항 중 하나인 '5년 동안 유지'에 대한 해결책이 전혀 없다. 이제 남은 것은 B와 D인데, 둘의 차이점은 그저 빅쿼리냐, 클라우드 스토리지냐일 뿐이다. 여기서 핵심은 '5년 이상'이라는 기간이 된다. 그렇기에 여기서는 D가 합당해 보인다. 클라우드 스토리지에서 콜드라인을 선택하면, 장기간 유지하는 데에 있어 합리적이다. 물론 빅쿼리도 저비용 스토리지 역할을 하기야 한다만, 빅쿼리는 저장보다는 분석이 주된 목표다.

 

27. Your company has decided to build a backup replica of their on-premises user authentication PostgreSQL database on Google Cloud Platform. The database is 4TB, and large updates are frequent. Replication requires private address space communication.
Which networking approach should you use?

• A. Google Cloud Dedicated Interconnect
• B. Google Cloud VPN connected to the data center network
• C. A NAT and TLS translation gateway installed on-premises
• D. A Google Compute Engine instance with a VPN server installed connected to the data center network

온프레미스 사용자 인증 PostgreSQL 데이터베이스의 백업 사본을 GCP에 구축한다. DB는 4TB이며, 대규모 업데이트가 빈번하다. 복제를 위해 개인 주소 공간 통신이 요구된다. 어떤 네트워킹 접근 방식을 선택해야 하는가.

 

B의 데이터 센터 네트워크에 연결된 VPN은 인터넷에서 데이터가 흘러가는 것을 고려해야 하고, 개인 연결에 대한 요구사항이 존재한다. 그리고 하이브리드 옵션이 딱히 언급되지 않은 상황에서 VPN이 데이터 센터를 얼마나 잘 연결하는지 확신을 가질 수 없다. https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview에서 내용을 확인할 수 있다. C의 경우, 이거는 외부에 도달할 수 있는 VM 옵션이므로 이 문제의 요구사항과는 거리가 멀다. D는 애당초 속도가 느리기 때문에 네트워킹에 있어 적합하다고 할 수 없다. 그렇기에 답은 A가 된다. 비싸기야 하다만, 대신 안전하고 빠른 연결을 보장하는 구글 클라우드 전용 인터커넥트가 가장 합당하다. 비용에 대한 문제가 명시되어 있지 않기에 더욱 A를 확신할 수 있다.

 

28. Auditors visit your teams every 12 months and ask to review all the Google Cloud Identity and Access Management (Cloud IAM) policy changes in the previous 12 months. You want to streamline and expedite the analysis and audit process.
What should you do?

• A. Create custom Google Stackdriver alerts and send them to the auditor
• B. Enable Logging export to Google BigQuery and use ACLs and views to scope the data shared with the auditor
• C. Use cloud functions to transfer log entries to Google Cloud SQL and use ACLs and views to limit an auditor's view
• D. Enable Google Cloud Storage (GCS) log export to audit logs into a GCS bucket and delegate access to the bucket

매 12월마다 이전 12개월 동안의 모든 구글 클라우드 IAM 정책 변경사항을 검토한다. 분석 및 감사 프로세스를 간소화하고 신속하게 진행하고자 한다. 어떻게 해야 하는가.

 

https://cloud.google.com/iam/docs/job-functions/auditing?hl=ko#scenario_external_auditors의 내용을 보았을 떄, B가 합당한 것으로 보인다. D의 경우가 가장 헷갈리는 대상이었는데, 여기서 데이터는 12개월 동안 보존을 할 필요는 없다. 분석의 간소화와 신속이라는 측면에서 B가 합리적이다.

 

29. You are designing a large distributed application with 30 microservices. Each of your distributed microservices needs to connect to a database back-end. You want to store the credentials securely.
Where should you store the credentials?

• A. In the source code
• B. In an environment variable
• C. In a secret management system
• D. In a config file that has restricted access through ACLs

30개의 마이크로서비스 대규모 분산 애플리케이션을 설계한다. 분산 마이크로서비스는 가각 DB 백엔드에 연결해야 한다. 자격 증명을 안전하게 저장하고자 할 때, 어디에 저장해야 하는가.

 

구글 시크릿 매니지먼트 자체가 이런 목적을 위해 설계되었다. 그렇기에 C가 정답이 된다. 소스 코드와 소스 컨트롤에 자격증명을 저장하는 것은 소스 코드에 엑세스할 수 있는 사람이라면 누구나 평문으로 검색할 수 있기 때문에 A는 절대 해서는 안되는 선택이다. 또한 자격 증명이 로테이션할 때마다 코드를 업데이트하고 배포를 수행해야 하는데, 세션이 지속될 떄 환경 변수를 지속적으로 채워야 하므로 B는 적합하지 않다. D가 잘못된 이유는 구성 파일에 대한 엑세스를 관리하고 키가 회전할 때 수동으로 업데이트하는 대신 키 관리 시스템을 활용하는 것이 낫기 때문이다. 또한 구성 파일에서 자격 증명이 평문으로 포함되어 있다면 당연히 위험은 증가할 수밖에 없다. 키 관리 시스템이 암호화 키를 생성, 사용, 회전, 암호화, 파괴하고 해당 키에 대한 권한을 관리하기 때문에 C가 무조건 정답이다.